Hi again. I was testing logrotate-3.7.2-6 with and without option 'dateext'. This is the test configuration of logrotate.conf: -------------------------------------------- rotate 6 missingok compress /log/file { daily create 0664 root root } -------------------------------------------- # ls /log file file.2.gz file.4.gz file.6.gz file.8.gz file.1.gz file.3.gz file.5.gz file.7.gz file.9.gz # logrotate -f -v /etc/logrotate.conf reading config file /etc/logrotate.conf reading config info for /log/file Handling 1 logs rotating pattern: /log/file forced from command line (6 rotations) empty log files are rotated, old logs are removed considering log /log/file log needs rotating rotating log /log/file, log->rotateCount is 6 renaming /log/file.6.gz to /log/file.7.gz (rotatecount 6, logstart 1, i 6), renaming /log/file.5.gz to /log/file.6.gz (rotatecount 6, logstart 1, i 5), renaming /log/file.4.gz to /log/file.5.gz (rotatecount 6, logstart 1, i 4), renaming /log/file.3.gz to /log/file.4.gz (rotatecount 6, logstart 1, i 3), renaming /log/file.2.gz to /log/file.3.gz (rotatecount 6, logstart 1, i 2), renaming /log/file.1.gz to /log/file.2.gz (rotatecount 6, logstart 1, i 1), renaming /log/file.0.gz to /log/file.1.gz (rotatecount 6, logstart 1, i 0), old log /log/file.0.gz does not exist renaming /log/file to /log/file.1 creating new log mode = 0664 uid = 0 gid = 0 compressing log with: /bin/gzip removing old log /log/file.7.gz # ls /log file file.1.gz file.2.gz file.3.gz file.4.gz file.5.gz file.6.gz file.8.gz file.9.gz ####################################################################### Above you can see only one log being removed. Logs file.8.gz and file.9.gz weren't touched. Old file.7.gz is overwritten, I think. Now using the same configuration, but adding 'dateext': # ls /log file file-20051001.gz file-20051005.gz file-20051009.gz file-20050928.gz file-20051002.gz file-20051006.gz file-20051010.gz file-20050929.gz file-20051003.gz file-20051007.gz file-20051011.gz file-20050930.gz file-20051004.gz file-20051008.gz file-20051012.gz # logrotate -f -v /etc/logrotate.conf reading config file /etc/logrotate.conf reading config info for /log/file Handling 1 logs rotating pattern: /log/file forced from command line (6 rotations) empty log files are rotated, old logs are removed considering log /log/file log needs rotating rotating log /log/file, log->rotateCount is 6 removing old log /log/file-20050928.gz removing old log /log/file-20050929.gz removing old log /log/file-20050930.gz removing old log /log/file-20051001.gz removing old log /log/file-20051002.gz removing old log /log/file-20051003.gz removing old log /log/file-20051004.gz removing old log /log/file-20051005.gz removing old log /log/file-20051006.gz renaming /log/file to /log/file-20051013 creating new log mode = 0664 uid = 0 gid = 0 compressing log with: /bin/gzip removing old log /log/file-20051007.gz # ls /log file file-20051009.gz file-20051011.gz file-20051013.gz file-20051008.gz file-20051010.gz file-20051012.gz You can see that with 'dateext', logrotate first removes all old logs until only 6 files remain (option 'rotate 6'), then does rotation, which creates a new file, and finally removes one more file to keep file count equal to 6. Removal of all old files is great to make sure disk space isn't wasted, but without 'dateext' only one log is removed each time and needs sufix with a successive number. I think both configurations should follow the same process, or at least a note should be included in man page, then if old logs with sufix numbers greater then rotate count exist, the the user shall removes them manually.
I think logrotate should ignore "rotate count" when "dateext" option is used, because there is no real log rotation in dateext scenario. Old logs should be left untouched unless maxage is used. Do u agree?
fix candidate http://people.redhat.com/pvrabec/rpms/logrotate-3.7.2-11.src.rpm
I think there is a good number of servers that are running with "dateext" and using "rotate count", not "maxage" to limit the number of logs archived, so ignoring it would cause problems to many system admins. After post this bug report I thought if someone would care about, because it is just a different behavior and "dateext" wasn't doing bad things, but I left the bug untouched to at least document the differences, and see if someone have a good idea to end with these differences and don't confuse sysadmins.
There are two options left: 1. Delete the old logs in the scenario without dateext 2. Let it be Personally I'm in favour of 2. -- I just don't see this as a bug.
This report seems to be inactive and since I don't think the default behaviour is buggy in any way, I'm closing it.