Description of problem: Configuration entries with glob (like /var/log/httpd/*) will match old (.n, .n.gz) files on 2nd and subsequent rotations. How reproducible: Always Steps to Reproduce: 1. /var/log/httpd initially has two files: access_log and error_log 2. logrotate config entry looks like this: /var/log/httpd/* { rotate 8 ... other options ... } Actual Results: First rotation: access_log => access_log.1 error_log => error_log.1 access_log and error_log are empty. Second rotation: access_log.1 => access_log.2 access_log => access_log.1 access_log.1 => access_log.1.1 error_log.1 => error_log.2 error_log => error_log.1 error_log.1 => error_log.1.1 access_log, error_log, access_log.1 and error_log.1 are empty. Expected Results: .n files should be skipped from second rotation Proposed solution: before returning from readConfigFile(), inspect all log entries and remove unneccessary items from log->files list (this cannot be done right after glob() because corresponding extension and compressext options are not read yet)
The main problem is that now you are asking to filter out files that match '\.[0-9]+(\.gz)?$' (regex, not glob), which could possible include some files that people really want rotated. It's better for logrotate to behave as instructed, even if it is little "dumber". The right solution is to just list the files that you actually want rotated, e.g. /var/log/httpd/access_log /var/log/httpd/agent_log /var/log/httpd/error_log /var/log/httpd/referer_log { ... This is the way the Red Hat /etc/logrotate.d/apache file does it, and it solves the problem you describe.