From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 Description of problem: size and monthy not working together when use in same conf file. Version-Release number of selected component (if applicable): logrotate-3.5.8-1 How reproducible: Always Steps to Reproduce: 1.configure the /etc/logrotate.d/apache to use size 20M and monthy. 2.Create or have through normal use some 20M or larger log files. 3.Let time pass enough to run the cron jobs at least once. Actual Results: The larger then 20M files never got rotated but however, when the month passes, they all get rotated as expected. Expected Results: When the daily cron runs logrotate, the file greater then 20M sould been roated while the smaller ones are left alone and all files get rotated each month. Additional info: Currently using logrotate-3.5.8-1 that was --rebuild from .src.rpm using a slighly change rpmconf to use highest march instead of i386 for all builds. In my case, march=i586 through the use of RPM_OPT_FLAGS. Apache logconf is this: /var/log/httpd/*_log { size 20M monthly rotate 260 sharedscripts postrotate /bin/kill -HUP `cat /var/run/httpd.pid 2>/dev/null` 2> /dev/null || true endscript } When I comment out monthy and do a /usr/sbin/logrotate -d /etc/logrotate.conf, I get this: (trimed down) rotating pattern: /var/log/httpd/*_log 20971520 bytes (260 rotations) empty log files are rotated old logs mailed to root rotating file /var/log/httpd/access_log log does not need rotating an so on... When monthy is not commented out, I get: (trimed down) Handling 12 logs rotating pattern: /var/log/httpd/*_log monthly (260 rotations) empty log files are rotated old logs mailed to root rotating file /var/log/httpd/access_log log does not need rotating and so on...
logrotate only allows one rotation criteria - the real bug is that it doesn't warn when people specify multiple criteria in the same entry. AFAICS it is also not very practical to produce a warning, due to the way logrotate uses include files to layer settings that intentionally override each other. So all I can really promise is to accept a patch that fixes the problem without losing existing functionality.