syslog log rotation

James Ralston qralston+ml.inn-workers at
Tue Apr 24 20:27:00 UTC 2001

On 24 Apr 2001, Alex Kiernan wrote:

> 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

There's a race condition here: something else can come along and HUP
syslogd after the "mv" but before the "cat", creating a window where
messages from inn can be lost (until the "hupsyslogd" command occurs).

In short, anything that deals with files that syslog is writing must
assume that syslog can be reloaded at any time, and therefore must
never create a window where a filename that syslog is configured to
write to does not exist.

This solution will avoid the race condition:

    ##  Move syslog files.
    for F in ${SYSLOGS}; do
        rm -f "${F}.old"
        ln "${F}" "${F}.old"
        cat /dev/null >"${F}.new"
        mv "${F}.new" "${F}"
    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 type
> file).

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

My $0.02: integrate it.  What INN currently does (zeroing files that
syslog is actively writing to) is a hack.  (Making a setuid-root
hupsyslogd program is arguably also a hack, but IMO, it's a much
cleaner one.)

James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA

More information about the inn-workers mailing list