How does logrotate handle open files? Can logrotate rotate files that a process has open?
Best Answer
For those applications that don't accept the signals from logrotate as Rory described, I use a couple of methods.
Use the copytruncate option
Add a post-rotate statement to restart the service
The decision of which one to use depends on both size of log files and necessity of seamless logs. That's going to be a risk analysis on your own part. However, to give an example, I use a post-rotate restart on certain logs where I actually should be using a copytruncate. However, the files are often several gigs and the copy could take a long enough time that losing a second or two each night was preferable.
I combined logrotate with some shell magic to get the desired effect. Basically logrotate is still in charge of moving and compressing the files, and then kicking off the script needed to delete the old files as well as ensuring the directory doesn't have more than 50 or so files. Here is what I did:
/mycores/core_* {
compress
daily
missingok
nocreate
nodelaycompress
olddir /mycores/old
sharedscripts
postrotate
# delete all core_*.gz files older than 28 days
find /mycores/old -name "core_*.gz" -mtime +28 -delete
# make sure we have a max of 50 files; delete the oldest files if we have too many
for filename in $(find /mycores/old/ -name "core_*.gz" -printf "%T+ %p\n" | sort --reverse | tail --lines=+51 | cut -d' ' -f2); do rm $filename; sleep 0.5; done
endscript
}
I'm not the best bash scripter out there, so that postrotate script section might be heavier than necessary... :)
I believe it's the content of the state file, which is my case is /var/lib/logrotate.status. Each file has one line, which is the date on which it was last rotated; if you run logrotate on such a date that a given file is due for rotation, given the number of days between current date and the date in the file (1 for daily, 7 for weekly, etc.), the file will be rotated.
logrotate doesn't seem to care at what time of day it's run; even if it usually runs at 2355, if you were to run it at 0130 instead, it would still rotate files marked daily and last done yesterday; but having done so it would put today's date into the state file (against any rotated files), so a second run at 2355 would do nothing.
Best Answer
For those applications that don't accept the signals from logrotate as Rory described, I use a couple of methods.
The decision of which one to use depends on both size of log files and necessity of seamless logs. That's going to be a risk analysis on your own part. However, to give an example, I use a post-rotate restart on certain logs where I actually should be using a copytruncate. However, the files are often several gigs and the copy could take a long enough time that losing a second or two each night was preferable.