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 situations).
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. Stefan