Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 May 1999 19:22:03 -0700
From:      Graeme Tait <graeme@echidna.com>
To:        James Wyatt <jwyatt@rwsystems.net>
Cc:        Roger Marquis <marquis@roble.com>, freebsd-isp@freebsd.org
Subject:   Re: Web Statistics break up program.
Message-ID:  <3744C34B.409E@echidna.com>
References:  <Pine.BSF.4.05.9905201027590.18069-100000@kasie.rwsystems.net>

next in thread | previous in thread | raw e-mail | index | archive | help
James Wyatt wrote:
> 
> On Tue, 18 May 1999, Roger Marquis wrote:
> > This will create an archived logfile (http.site.May_1999) and erase
> > the original without needing to kill -1 the httpd.
> >
> >       #!/bin/sh -
> >       LOGDIR=/var/log
> >       ARCDIR=/var/log/oldlogs
> >       DAY=`date | awk '{ OFS="_" ;print $2,$6}' `
> >       for log in $LOGDIR/http* ; do
> >               cp $log $ARCDIR/${log}.${DAY}
> >               chmod 440 $ARCDIR/${log}.${DAY}
> >               cp /dev/null $log
> >       done
> 
> And on several of our servers will miss some events we need in the log.
> Any entries that fall between the two 'cp' commands get zapped. (btw: It
> would be better to move the 'chmod' after the second 'cp' to reduce this)
> These events will be gone forever and may represent billable or auditable
> content. beware... What is wrong with signalling the server once a day?


A 'kill -1' causes Apache to immediately kill off all the server children, 
aborting transfers in progress - not too good for a busy commerce server. In 
addition, new children must be spawned, causing a hiatus of a few seconds 
(sometimes appreciably more) with incoming requests piling up until full 
performance is restored. A 'kill -1' also zeros out server statistics. Doing 
all this seems a bit silly just to rotate log files.

The server I run almost never has a moment without at least several 
transfers in progress. Some are possibly of large files, and aborting those 
transfers is particularly annoying to users. But aborting a secure server 
transaction really looks bad, especially if the server state has been 
changed and the user fails to get the appropriate response (e.g., an order 
has been accepted, but no confirmation appears, just some "connection lost" 
type message). Also, what happens to CGI processes in progress?

At the same time, I don't really like the way 'kill -USR1' works. Someone 
suggested using the Apache rotatelogs program, and I will be looking into 
that again (I had previously tried it, but was disatisfied with the limited 
flexibility, e.g., daily rotates occurring at around 00:00:00 UTC).

With all the features and flexibility built into Apache, it seems 
disappointing that the log rotation issue doesn't seem to have been 
addressed better.


-- 
Graeme Tait - Echidna



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-isp" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3744C34B.409E>