The man page of logrotate
says that:
It can be used when some program cannot be told to close its logfile
and thus might continue writing to the previous log file for some
time.
I'm confused by this. If a program cannot be told to close its logfile, it will continue to write forever, not for sometime. If the compression is postponed to next rotation cycle, the program continues to write to that file even after the next rotation cycle. How is postponing solving the problem?
My understanding is that copytruncate
should be used when a program cannot be told to close the logfile. I'm aware that some data written to the logfile gets lost when the copy is in progress.
I was looking at the logrotate file for couchdb, and it had both copytruncate
and delaycompress
options.
/usr/local/couchdb-1.0.1/var/log/couchdb/*.log {
weekly
rotate 10
copytruncate
delaycompress
compress
notifempty
missingok
}
It looks like there is no point using delaycompress
when copytruncate
is already there. What am I missing?
Your understanding of
copytruncate
is correct, but the wording in the manpage fordelaycompress
is a little misleading. More properly, it should say "when some program cannot be told to immediately close it's logfile" -- for instance, if you're using sharedscripts and the script sends a signal to the process using the log when all the log files have been rotated.We use:
This creates fixed copy of the apache
access_log
access_log.1
so that we can then run our Stats package as a script at the end of the day.The following day logrotate compresses the file creating
access_log.2.zip
Not sure if I completely understand your question, but if you're asking what I think...I use this:
That's a nice (or at least a) way to kill the log and move to the next. For "programs" that suck, such as Cisco's ASA platform that log tons of data per second, it works.
The reason for this is when software performs its own rotation. This is usually done by copying the current log to a newly created file, then truncating the original. This can take some time and logrotate don't have any mechanism to signal back that a file is ready to be compressed.
Logrotate can be used only to compress and maintain archives rather than performing the actual rotation.