Description of problem: I cannot get logrotate to rotate logs daily but based on a 'calendar' month. That is, 30 daily logs for a 30-day month, 31 logs for a 31-day month, etc. I can currently set: daily start 1 rotate 31 but this rotates the logs 31 times, and therefore is not correct for months with 30 or 28/29 days. Version-Release number of selected component (if applicable): logrotate-3.7.5-3.1.fc7 How reproducible: Look at file /etc/logrotate.d/psacct (it contains 'daily; rotate 31'). When a month has 30 days the log files will rotate 31 times. The file '.31' will actually relate to the first day of 2 months previously rather than the first day of the previous month. (Sorry, sounds complicated, you need to work it out in your head :-) ) Steps to Reproduce: 1. Create a logrotate config file using the 'daily; rotate 31' options. 2. Leave for a couple of months. 3. Look at the log file contents (assuming they record the date). Actual results: One or more of the rotated files will contain information not relating to the previous month (but relates to the month before that). Expected results: When processing monthly data from daily log files, it would be nice to know that the log files relate to the previous month without having to check all the date/times. Additional info: A possible workaround might be to run some in-house script via cron to remove rotated log files that are not from the previous month. However, since logrotate knows if the month has changed or not (because of the 'monthly' option), it should be easy enough for it to 'dynamically' decide how many log files there should be for the previous month. Perhaps an additional value for the 'rotate' option could be used to indicate that only a calendar months worth of files is to be kept. Alternatively, a separate additional option to be used when 'daily' is used. It is appreciated that with Fedora 7, logrotate runs via cron at around 4am. Hence for true monthly data, it would be necessary to modify the crontab entry so that logrotate runs closer to midnight. That is not a problem for the sysadmin, and even if left as-is would involve only 4 hours of extra data. However, the problem is that at present processing of the previous months log files could involve several *days* worth of extra data (because in March February's 28 log files will actually be rotated 31 times - almost 3 days of data from the previous month). I suspect, but haven't tried, the 'dateext' option would make the effect easier to notice, and perhaps easier to then ignore files from the wrong month. However, this seems unnecessary when logrotate could easily calculate the number of log files which should be present.
How many files would you like logrotate to rotate on 13th March?
One. The 'daily' option is set, so just one log to be rotated. It is only on the first day of a month (because the month has changed) that anything special would be required to happen.
One? I'd say thirteen at least. "One" means that you end up with "log" and "log.1" on 13th March in the evening. The Fedora 8 logrotate will have the dateext option set by default which makes you easily tell what log comes from what day and, as you already noted, you can use that to solve your demand. I'm sorry but the feature you ask me to add I don't see as much useful.