[NBLUG/talk] Apache Logs..

ME dugan at passwall.com
Wed Apr 2 11:28:01 PST 2003


As a guess, the cron job is stopping and restarting your web server to
"rotate" the log files.

When stopping apache, a SIGHUP will ask the apache "child processes"
(started by apache based on the number of "MinServers" you specify in the
httpd.conf, or number of servers running when the crinjob starts.) A
SIGHUP is kind of a nice way of asking apache to kill itself gracefully.

However, the log rotate needs to happen. After waiting for what the cron
script coders felt was a sufficient time, they then go back to see if the
SIGHUP made each apache child process die. If the SIGHUP was not
successful (as a result of not enough time, or not dealing with the SIGHUP
(for some reason) then the script steps up to sending each apache child
process a SIGTERM (-9) signal. A SIGTERM is an unkind killing of a
process. This is where the system effectively "kills" the process.

A kill -9 is unkind in that it does not permit the application being
killed to save its unsaved data, and flush desired changes to files not
passed to the OS.

So summary:
Probably a cron script that is rotating your apache log files.
First ths script tries a SIGHUP to ask each to die and save data.
When the request fails to complete this in a timely manner (according to
the script) it then sends each a SIGTERM to make sure they are dead before
restarting apache (after the logfile is rotated.)

Where to find these scripts... For Debian: /etc/cron.* folders contains
many scripts to be run on a per application basis.

If you dont find anything there, you can try to check out /var/spool/cron
for possible scripts.

(the script in /etc/cron.*/ will probably have apache in the name:)
# find /etc/ -iname \*apache\* -print
may be useful.

HTH,
-ME



Christopher Wagner said:

> I'm getting these every day in my /var/log/httpd/error_log when my daily
> cron cycle happens.  This box is a production box running Redhat 7.2 and
> Apache 1.3.27.  Any ideas?  The machine seems to be running fine
> otherwise..
> I noticed when I was looking through the logs laughing at all the silly
> IIS
> exploit attempts (I get about 3-6 each day).  :)
>
> [Wed Apr  2 04:02:27 2003] [warn] child process 9401 did not exit, sending
> another SIGHUP
> [Wed Apr  2 04:02:28 2003] [warn] child process 9402 did not exit, sending
> another SIGHUP
> [Wed Apr  2 04:02:28 2003] [warn] child process 9403 did not exit, sending
> another SIGHUP
> [Wed Apr  2 04:02:28 2003] [warn] child process 9404 did not exit, sending
> another SIGHUP
> [Wed Apr  2 04:02:28 2003] [warn] child process 9405 did not exit, sending
> another SIGHUP
> [Wed Apr  2 04:02:28 2003] [warn] child process 9809 did not exit, sending
> another SIGHUP
> [Wed Apr  2 04:02:28 2003] [warn] child process 9810 did not exit, sending
> another SIGHUP
> [Wed Apr  2 04:02:28 2003] [warn] child process 9811 did not exit, sending
> another SIGHUP
> [Wed Apr  2 04:02:28 2003] [warn] child process 10029 did not exit,
> sending
> another SIGHUP
> [Wed Apr  2 04:02:28 2003] [warn] child process 10473 did not exit,
> sending
> another SIGHUP
> [Wed Apr  2 04:02:29 2003] [warn] child process 9401 still did not exit,
> sending a SIGTERM
> [Wed Apr  2 04:02:29 2003] [warn] child process 9402 still did not exit,
> sending a SIGTERM
> [Wed Apr  2 04:02:29 2003] [warn] child process 9403 still did not exit,
> sending a SIGTERM
> [Wed Apr  2 04:02:29 2003] [warn] child process 9404 still did not exit,
> sending a SIGTERM
> [Wed Apr  2 04:02:29 2003] [warn] child process 9405 still did not exit,
> sending a SIGTERM
> [Wed Apr  2 04:02:29 2003] [warn] child process 9809 still did not exit,
> sending a SIGTERM
> [Wed Apr  2 04:02:29 2003] [warn] child process 9810 still did not exit,
> sending a SIGTERM
> [Wed Apr  2 04:02:29 2003] [warn] child process 9811 still did not exit,
> sending a SIGTERM
> [Wed Apr  2 04:02:29 2003] [warn] child process 10029 still did not exit,
> sending a SIGTERM
> [Wed Apr  2 04:02:29 2003] [warn] child process 10473 still did not exit,
> sending a SIGTERM
>
> - Christopher Wagner
> chrisw at pacaids.com
>
> Packaging Aids Corporation - Information Systems
> P.O. Box 9144
> San Rafael, CA 94912-9144
> http://www.pacaids.com/
> (415) 454-4868 x116
>
> _______________________________________________
> talk mailing list
> talk at nblug.org
> http://nblug.org/mailman/listinfo/talk
>
>




More information about the talk mailing list