[NBLUG/talk] Apache Logs..

Christopher Wagner chrisw at pacaids.com
Fri Apr 4 10:56:01 PST 2003


In /etc/logrotate.d/apache I have:
--
/var/log/httpd/access_log /var/log/httpd/agent_log /var/log/httpd/error_log
/var/log/httpd/referer_log {
    missingok
    sharedscripts
    postrotate
        /bin/kill -HUP `cat /var/run/httpd.pid 2>/dev/null` 2> /dev/null ||
true
    endscript
}
--
I'm assuming the line I wish to change is the postrotate command.  Eric
suggested:
"apachectl graceful && apachectl status > /dev/null".  Is this good?  This
isn't a high traffic web server.  I'm not terribly concerned if the web
server is inaccessible for, say, up to a minute or so in the middle of the
night if it means I will be nicer to my machine for it.

Thanks for your time folks..

- 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
 

-----Original Message-----
From: talk-admin at nblug.org [mailto:talk-admin at nblug.org]On Behalf Of ME
Sent: Thursday, April 03, 2003 4:37 AM
To: talk at nblug.org
Subject: Re: [NBLUG/talk] Apache Logs..


Eric Eisenhart said:
> On Wed, Apr 02, 2003 at 06:41:17PM -0800, ME wrote:
[chop]
>> If you want to educate logrotate on how to gracefully stop apache, then
>> you can send a SIGTERM to the parent process for apache and that should
>> stop apache. As an alternative, you may be able to educate logrotate on
>> how to use apachectl and pass it the arg "stop" and start for a graceful
>> shutdown.
>
> SIGTERM?   Yikes.
>
> With apache, it's best to do the least damage required for the job.
> Absolute least damage is SIGUSR1 (apachectl graceful[1]), which will wait
> for
> existing connections to finnish and then reload the configuration and
> reopen
> all log files.  Next least damage is SIGHUP (apachectl restart), which
> will
> kill existing connections immediately and then reload the configuration
> and
> reopen all log files.  If you stop and then start with SIGTERM (apachectl
> stop), the service is totally unavailable for a period of time
> ("connection
> refused").  With USR1 and HUP, during the restart those connections get
> queued and then handled after it's running again.  Even on a very busy
> server, SIGUSR1 (apachectl graceful) will feed out all data it's supposed
> to, merely delaying responses for a moment to some clients.
>
> In the case of logrotation, SIGUSR1 has the problem that it's not
> instantaneous (while SIGHUP is).  Better to just wait....  Say, "apachectl
> graceful && apachectl status > /dev/null", perhaps?

There is risk in this. If a large file is being transferred, an effective
DoS can prevent log rotation from occuring. Being unkind to users (say
once a month) and just stopping the service without letting connections
finish is faster for scripts that need a level of guarantee that proccess
that have opened files, are no longer writing to them when they are moved
(possibly across mounted partitions.) The apache man page (man httpd)
mentions use of SIGTERM to the httpd parent process to dtop apache.

Also, check out your apachectl script that comes with apache. When you:
#apachectl stop
it sends a sigterm (default kill signal unless another signal is
specified) to the parent httpd process.

The difference here, is that it appears logrotate is sendig a sigterm to
the parent and each of the children too, when a single sigterm to the
parent should suffice, and the SIGHUP just ask each process top flush
unwritted log data and re-read config.

-ME

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-----) C++$(++++) U++++$(+$) P+$>+++
L+++$(++) E W+++$(+) N+ o K w+$>++>+++ O-@ M+$ V-$>- !PS !PE Y+ PGP++
t at -(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+>++>++++ h(++)>+ r*>? z?
------END GEEK CODE BLOCK------
decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html

_______________________________________________
talk mailing list
talk at nblug.org
http://nblug.org/mailman/listinfo/talk



More information about the talk mailing list