[users@httpd] mod_info loads on one server but not on the other

[j k <jo...@gmail.com>]

running apache 2.0.59-r5 on two almost identical servers (both dual core
intel cpus but not same speed) with identical config files on both.

The only other difference between the two servers is that I have an extra
kernel network  driver module built-in on the backup server that works
correctly. I've done the same on the production server but have not yet
rebooted it so it is running slightly different kernel.

On one server mod_status, mod_info and mod_access all load but on the other
they don't.
 I can see this from the phpinfo() list of loaded modules for each.

same conf for both:
APACHE2_OPTS="-D DEFAULT_VHOST -D SSL_DEFAULT_VHOST -D CGI -D PHP5 -D SSL -D
PYTHON -D PERL -D INFO"

Background:
i'm running gentoo linux on a production server and needed to end the use of
php4, so to stop the heart palpitations that come from rebuilding lots of
apps at the same time on a live server, I set up a backup server and cloned
the production server onto it. On the backup I nixed php4 and updated php5
to the latest, restarted apache and after a few php.ini tweaks all went much
better than I expected: few errors.
Heartened with the trial result I  tried the same on the production server
and everything went well except that for some reason server-status and
server-info are no longer working, they return a 404 file not found.
Everything else seems perfect.

Here's most probably where the problem lies:
I noticed when I restarted apache on the production server only it gives
start-up errors:

# /etc/init.d/apache2 restart

: command not found: line 2:

: command not found: line 25:

: command not found: line 31:

: command not found: line 34:

: command not found: line 39:

: command not found: line 43:

: command not found: line 50:

 * Stopping apache2 ...                                                   [
ok ]

 * Starting apache2 ...                                                   [
ok ]

can't see anything susicious in the error log in fact it's the exact same
messages as on the one that works correctly.

I looked in /etc/init.d/apache2 and can't for the life of me see what those
lines refer to, the line numbers make no sense. I'm guessing that apache is
not loading some part of the http.conf file, likely around about where it
loads the modules in question.
What's strange is that I can copy the entire /etc/apache2 folder from the
server where it doesn't work right over to the other overwriting it's
apache2 folder, restart apache there and everything works just fine. I don't
get it...what's happening here?

[users@httpd] Re: mod_info loads on one server but not on the other

[j k <jo...@gmail.com>]

On Nov 30, 2007 10:45 PM, j k  wrote:

> running apache 2.0.59-r5 on two almost identical servers (both dual core
> intel cpus but not same speed) with identical config files on both.
>
> The only other difference between the two servers is that I have an extra
> kernel network  driver module built-in on the backup server that works
> correctly. I've done the same on the production server but have not yet
> rebooted it so it is running slightly different kernel.
>
> On one server mod_status, mod_info and mod_access all load but on the
> other they don't.
>  I can see this from the phpinfo() list of loaded modules for each.
>
> same conf for both:
> APACHE2_OPTS="-D DEFAULT_VHOST -D SSL_DEFAULT_VHOST -D CGI -D PHP5 -D SSL
> -D PYTHON -D PERL -D INFO"
>
> Background:
> i'm running gentoo linux on a production server and needed to end the use
> of php4, so to stop the heart palpitations that come from rebuilding lots of
> apps at the same time on a live server, I set up a backup server and cloned
> the production server onto it. On the backup I nixed php4 and updated php5
> to the latest, restarted apache and after a few php.ini tweaks all went
> much better than I expected: few errors.
> Heartened with the trial result I  tried the same on the production server
> and everything went well except that for some reason server-status and
> server-info are no longer working, they return a 404 file not found.
> Everything else seems perfect.
>
> Here's most probably where the problem lies:
> I noticed when I restarted apache on the production server only it gives
> start-up errors:
>
> # /etc/init.d/apache2 restart
>
> : command not found: line 2:
>
> : command not found: line 25:
>
> : command not found: line 31:
>
> : command not found: line 34:
>
> : command not found: line 39:
>
> : command not found: line 43:
>
> : command not found: line 50:
>
>  * Stopping apache2 ...
> [ ok ]
>
>  * Starting apache2 ...
> [ ok ]
>
> can't see anything susicious in the error log in fact it's the exact same
> messages as on the one that works correctly.
>
> I looked in /etc/init.d/apache2 and can't for the life of me see what
> those lines refer to, the line numbers make no sense. I'm guessing that
> apache is not loading some part of the http.conf file, likely around about
> where it loads the modules in question.
> What's strange is that I can copy the entire /etc/apache2 folder from the
> server where it doesn't work right over to the other overwriting it's
> apache2 folder, restart apache there and everything works just fine. I don't
> get it...what's happening here?
>

The error messages seems to have been caused blank lines in
/etc/conf.d/apache2  Once I deleted those lines: no startup or configtest
errors...
BUT apache still does not load mod_access, mod_info and mod_status for some
reason. It used to do this before I updated PHP.

I guess that must have to do with the APACHE2_OPTS
OK that's fixed also now (gremlins)
I had changed the line from:
APACHE2_OPTS="-D DEFAULT_VHOST -D SSL_DEFAULT_VHOST -D CGI -D PHP5CGI -D
PHP4 -D SSL -D PYTHON -D PERL -D INFO"
to
APACHE2_OPTS="-D DEFAULT_VHOST -D SSL_DEFAULT_VHOST -D CGI -D PHP5 -D SSL -D
PYTHON -D PERL -D INFO"
by deleting out the php4 stuff and that seems to be what broke it (it's not
like I changed that part of the line and PERL was loading).
To fix it I cut -D INFO from the end and put it just before -D PERL and now
it works, like I say: gremlins. Who knows? And now I've put it back where it
was and it also works!
 I guess why ask why. Happy that it is working again.