[syslog-ng] syslog-ng 1.1.7 released
Tue, 27 Apr 1999 17:49:56 -0400
Richi Plana said:
> One problem Un*x systems administrator haven't totally agreed on is
> how to rotate the logs if there was no way to reset the daemon which
> had opened the log (and kept it open). The problem has to do with
I have never had such a problem and any such program should just
be fixed (or not be used).
> filehandles. Some programs open a log and keep it open instead of
> closing and reopening them when the need arises. Some admins say log
> rotators should just cp the log to a backup and do the equivalent of a
> 'cat /dev/null > logfile'. (which may cause some problems in some
You'll end up creating big sparse files, which is OK except that `cp'
will most likely not keep the sparseness so the backups will be big
mostly empty (but not sparse) files.
> Personally, I believe there to be three solutions to log rotation: 1)
> If the program doesn't support log rotation, kill the daemon, rotate
> the logs and restart the program; 2) if the program only supports
> SIGHUP to re-read the configs and close and reopen the logs, just cp
> the file and SIGHUP it; and, 3) (the best solution) if the program
> supports a way to close, mv and reopen a new log file, then all your
> problems are solved. If you don't like the name the program used for
> the backup, just mv it.
Solution 2 is bogus because it suffers from a race condition.
You really don't want to use `cp' but `mv' there:
mv log log.bak
touch log; chmod 640 log
kill -HUP <daemon>
Solution 3 is only acceptable if the destination of the `mv' is known
so that you can easily do postprocessing of this backed up log file.
I'm thoroughly against any logrotation support in any program, except
for the usual reopen-upon-sighup. The few programs that support it
never support a wide enough range of alternatives. Log rotation is
better served by separate tools. Of course, as long as you can turn
off the logrotation (and use the conventional mv+sighup method), it's
only a question of wasted resources (human resources for coding, mostly)
and an additional source of bugs.