syslog log rotation

Russ Allbery rra at stanford.edu
Sun Aug 25 22:45:26 UTC 2002


I don't think I ever commented on this thread from last year about log
rotation, but conveniently nothing has changed in this area so my comments
are still current.  *wry look*

Let me quote the whole thing, since otherwise people likely wouldn't
remember any of the context:

Alex Kiernan <alexk at demon.net> writes:

> We've a recurrent problem when scanlogs runs overnight on a box which
> has all its disk NFS mounted (a NetApp). When syslog rotation happens
> the way Solaris & NFS interact causes us to get files, immediately
> post rotation, which are exactly the same size as those before, but
> entirely filled with zeroes (could be holes, I haven't checked), they
> then grow from the end of those files (albeit with some corruption in
> the first real block).

> The solution is to not use this chunk from scanlogs:

>     ##  Copy syslog files, truncating old inode since syslog has it open.
>     for F in ${SYSLOGS}; do
>  	rm -f ${F}.old
> 	cp ${F} ${F}.old
> 	cat /dev/null >${F}
>     done
>     ctlinnd -s logmode

> but instead do something like this:

>     ##  Move syslog files.
>     for F in ${SYSLOGS}; do
>  	rm -f ${F}.old
> 	mv ${F} ${F}.old
> 	cat /dev/null >${F}
>     done
>     hupsyslogd
>     ctlinnd -s logmode

> where hupsyslogd is a news only setuid root program which sends a
> SIGHUP to syslogd (using a compiled in path to a syslogd.pid type
> file).

> Is it worth figuring how to integrate this cleanly, or should I just
> make hupsyslogd.c available for dropping into contrib?

To my mind, the fundamental problem here is that INN is attempting to
handle rotation of syslog files, which is something that shouldn't be done
by a user other than root (since syslogd needs to be HUP'd).  I think
having a setuid program is something of a hack, and I also think that most
of us who are managing servers already have some other mechanism in place
for managing syslog log files.  For example, I use:

    <http://www.eyrie.org/~eagle/software/newsyslog/>

for such things.

So rather than trying to add various log rotation policy stuff into
scanlogs, what I'd really love to see is to provide some way of getting
scanlogs out of the loop entirely, and try to make all the log rotation
stuff optional.  Then those of us with our own software to handle such
things can use it and point INN at the results for its nightly summaries.

So under my thought, scanlogs would only handle those logs written
directly by INN, like the news log, and leave the syslog logs to some
other mechanism.

The difficulty with this idea is that scanlogs also coordinates the
rotation of logs with pausing the server and flushing logs so that one
gets a consistent snapshot of the server state.  But most log rotation
programs have ways of running programs before and after the actual log
rotation.

So my thought is this:  Continue to maintain the code in scanlogs to do
the work that it currently does, but also add two different modes, one to
flush the logs in the server and get ready for syslog logs to be rotated,
and one to do all the work done after the logs have been rotated, setting
things up for reporting.  And pull the reporting portions out of scanlogs
into a separate program.

Then, if you want, you can continue doing things as now.  Or you can tell
news.daily to not run log rotation, run log rotation yourself before
news.daily runs, and then tell news.daily to just use the results.

Does that make sense?  Do people think that would be a workable approach?

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.


More information about the inn-workers mailing list