In my experience, logrotate is great. It's very flexible, and works well with most software.
However, there are some issues with it, and as cronolog is primarily a web log rotation facility, I'll write down my experience with logrotate + apache which was problematic:
When rotating logs , we must notify apache that a log is being rotated, as even if logrotate renames access.log to access.log.1, apache will continue writing to access.log.1, as it is writing to the inode, and renaming the file doesn't affect the inode number.
On debian etch (and probably many other distros), logrotate is being used to rotate apache logs. Now, apache has a graceful restart that advises the apache child processes to exit once they finish serving existing connections, apache then re-reads it's configuration, spawns new child processes, which start writing to a new log file (In case the previous one was rotated).
This sounds like a great solution, however graceful restart does not always work in certain conditions (like heavy load), so debian developers decided to use an apache restart instead of a graceful restart, in the apache logrotate configuration. Unfortunetly this causes all connections to be dropped at once, which is very bad for heavily loaded sites. In addition, apache restart can also cause problems like apache stopping and not starting (also in certain load situations), see bug links below for details.
The bottom line is, logrotate is great, but can lead to certain issues for certain programs. I don't have much experience with cronolog, but as it writes logs through a pipe, it doesn't require any apache reloads when it's rotating log files, which basically solves all that is described above.
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
In my experience, logrotate is great. It's very flexible, and works well with most software.
However, there are some issues with it, and as cronolog is primarily a web log rotation facility, I'll write down my experience with logrotate + apache which was problematic:
When rotating logs , we must notify apache that a log is being rotated, as even if logrotate renames access.log to access.log.1, apache will continue writing to access.log.1, as it is writing to the inode, and renaming the file doesn't affect the inode number.
On debian etch (and probably many other distros), logrotate is being used to rotate apache logs. Now, apache has a graceful restart that advises the apache child processes to exit once they finish serving existing connections, apache then re-reads it's configuration, spawns new child processes, which start writing to a new log file (In case the previous one was rotated).
This sounds like a great solution, however graceful restart does not always work in certain conditions (like heavy load), so debian developers decided to use an apache restart instead of a graceful restart, in the apache logrotate configuration. Unfortunetly this causes all connections to be dropped at once, which is very bad for heavily loaded sites. In addition, apache restart can also cause problems like apache stopping and not starting (also in certain load situations), see bug links below for details.
The bottom line is, logrotate is great, but can lead to certain issues for certain programs. I don't have much experience with cronolog, but as it writes logs through a pipe, it doesn't require any apache reloads when it's rotating log files, which basically solves all that is described above.
Related logrotate/apache debian bugs: