[techtalk] Apache SIGTERM

[Almut Behrens]

On Wed, May 23, 2001 at 01:50:01PM -0400, s h wrote:
> Hi all,
> 
> I recently replaced the hard drive on my intranet webserver.  The old
> one had Redhat 7.0 installed, running apache-1.3.12-25.  My intranet
> site has a mysql database with a php frontend.  The packages I used were
> mod_php-3.0.12-1, mod_php-mysql-3.0.12-1, mysql-server-3.23.22.6, and
> mysql-2.32.22-6.  When I installed the new hard drive, I installed
> Redhat 7.1, with apache-1.3.19-5.  I installed the same packages for php
> and mysql as I had before, and copied over my old httpd.conf file, along
> with the entire docroot, with cp -Rpd to retain permissions.  I thought
> I had all my bases covered... but once I had all my packages installed,
> httpd will not start.  /var/log/messages only repeats what I already
> knew (httpd startup failed).  /var/log/httpd/error_log shows only this:
> 
> [Wed May 23 08:32:25 2001] [notice] Apache/1.3.19 (Unix) 
> (Red-Hat/Linux) mod_ssl/2.8.1 OpenSSL/0.9.6 DAV/1.0.2 PHP/4.0.4pl1
> mod_perl/1.24_01 configured -- resuming normal operations
> [Wed May 23 08:32:25 2001] [notice] suEXEC mechanism enabled (wrapper:
> /usr/sbin/suexec)
> [Wed May 23 09:54:00 2001] [notice] caught SIGTERM, shutting down

Hi Sally,

just making wild guesses:
to me it looks as if there's something wrong with the combination of
PHP versions (3 vs. 4). So, the first thing I'd check is whether all
PHP-related stuff either consistently refers to PHP3 or PHP4.
IIRC, your modules should reside in /usr/lib/apache/modules. Check
whether you've got libphp3.so or libphp4.so (or both?) in there.

The following short outline of the typical apache startup / dynamic
loading mechanics may not directly apply to what you have, but it'll
hopefully give you some ideas where to look:

The startup script /etc/rc.d/init.d/httpd tries to determine what
apache modules are available, and then starts httpd with a bunch of
-D options like -DHAVE_PHP4 -DHAVE_<anything> ...
The symbols defined in this way can be used in httpd.conf together
with the <IfDefine> directive to control which modules to load with
'LoadModule'/'AddModule'. The more recent default httpd.conf files
that come with the distros usually contain something like

<IfDefine HAVE_PHP3>                                                                            
  LoadModule php3_module    modules/libphp3.so                                                
</IfDefine>                                                                                     
<IfDefine HAVE_PHP4>                                                                            
  LoadModule php4_module    modules/libphp4.so                                                
</IfDefine>                                                                                     
...
and similarly for AddModule:

<IfDefine HAVE_PHP4>                                                                            
  AddModule mod_php4.c
</IfDefine>
...

then followed by further specifications within <IfModule> directives:

<IfModule mod_php4.c>                                                                           
  AddType application/x-httpd-php .php4 .php3 .phtml .php                                       
  AddType application/x-httpd-php-source .phps                                                  
</IfModule>                                                                                     
<IfModule mod_php3.c>                                                                           
  AddType application/x-httpd-php3 .php3                                                        
  AddType application/x-httpd-php3-source .phps                                                 
</IfModule>                                                                                     

Possibly, there are some inconsistencies here, when you mix PHP versions,
libs and httpd.confs...

Also, I faintly remember there being a php3.ini config file somewhere --
might be worth looking after...

Then, there's this mod_php-mysql-3.0.12-1 package. I'm not exactly sure
what it contains, but I assume it's some PHP DB driver module that's
linked with the mysql client-side libraries. Depending on whether it's
statically or dynamically linked (I guess dynamic), there might also
be problems with having it find the right version of shared object file.
It is probably ok as it is now (and was in your old RH7.0 setup), but
it might become relevant when you consider swichting to the new PHP4.
The related new mod_php-mysql-<whatever> package will then probably
also require a newer mysql lib...
The mysql server side is probably less critical, as communication is
via sockets, so, as long as the protocol spoken there doesn't change,
this is unlikely to cause trouble. I'd recommend that you leave the
server as it is for the moment -- that'll at least postpone potential
trouble resulting from attempts to convert all your data to a newer
mysql version ;)  (e.g. typically the number of columns in the grant
tables changes from version to version...)

> 
> Subsequent attempts to restart httpd only repeat the "caught SIGTERM,
> shutting down" message, with no other details.

hmm, I have no idea why that is... Also why is it SIGTERM and not
something more drastic like SIGSEGV, which I'd more typically expect to
see with libs crashing.
This message is what you normally get as well when you restart/stop
apache. So, the entries in the error_log don't necessarily indicate a
problem. On the other hand there are the entries in /var/log/messages,
and I do believe you that you figured out correctly that apache is not
running :)

> 
> Has anyone ever run across a similar situation?  And are there any other
> logs I can check that could shed any more light on what's going on?

not really, but you could try to set LogLevel to 'info' in httpd.conf,
which might give a few more lines in error_log (setting it to 'debug'
is usually of no use if the apache binary and modules haven't been built
with debug support -- but doesn't do any harm either).

And as a last resort I always recommend running apache under strace.
This will normally more or less immediately pin-point any problems with
files not being found, wrong files being used, etc. (and lots of other
things). Try running

  strace -f -o /tmp/strace.log /usr/sbin/httpd

or

  strace -f -e trace=file -o /tmp/strace.log /usr/sbin/httpd

In the strace.log you then get, work your way backwards starting at the
end of the file. Look for the SIGTERM, and try to make some sense of
the stuff you find a couple of lines above ;)

Things will get a little more involved, if you have a httpd.conf
making use of the new startup/loading concept outlined above. In this
case you'd have to supply all the -DHAVE_<anything> arguments to httpd
in exactly the way they are being supplied by the startup script
(/etc/rc.d/init.d/httpd) -- otherwise the results might not be
comparable... You could normally easily cut 'n paste these args from
the output of something like "ps axww | grep httpd", but that is not
going to help very much if you can't get the thing to start in the
first place ;) So you might consider putting a "set -x" or an
additional "echo `moduleargs`" in the startup script.
Alternatively, run the startup script itself under strace, though
this would clutter up the output quite a bit by adding a bunch of
superfluous forking contexts for the shell and all its subprocesses.
But then again, this probably doesn't apply in your case anyway, when
you are using your original old home-grown httpd.conf...


So, to sum up, I'm a little unsure what strategy to pursue. Either
you upgrade your packages to PHP4 (which might involve some yet unknown
follow-up work), or you arrange things consistently for PHP3 (probably
easier for now -- but there'll come the time when you want PHP4 ;)
Also, I wouldn't want to exclude the possibility that the old libs
might not play well together with some other parts of the new system
(things like newer libc and who knows what...).

Anyway, I may be talking utter garbage, because I'm typically neither
using PHP nor Red Hat (prefer mod_perl+TT2 and Debian instead -- but
I know that's not to the point here :)

- Almut