Description of problem:
Glob error halts logrotate even if missingok is specified
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create file logrotatetest.conf with these contents:
2. Run logrotate on this config file:
Logrotate command fails with this output:
error: error accessing /var/log/snort/*: No such file or directory
error: test1:2 glob failed for /var/log/snort/*/*kumquat
When run normally and this error occurs in a file in /etc/logrotate.d, all
processing of files stops, and logs are not rotated.
Logrotate treats failed glob as a missing logfile and completes silently. When
run normally and a glob failure occurs, other files in /etc/logrotate.d should
This is a pretty major bug. A simple case of attempting to rotate logs in a
directory that doesn't exist can lead to a complete, and mostly silent, failure
of all log rotation on the system.
Some services (for example Squid) will crash if they run out of log space and
with log rotate silently failing it happened to us recently. I'll admit that we
should have been monitoring free space on the /var mount point, however, this
system has run for years without issues and suddenly a failed glob was keeping
logs from rotating. This particular system can generate a lot of logs in burst,
but normally logrotate deals with this and compresses them nicely keeping plenty
of space. A silent failure for more than three weeks led to down time.
Any hope that this will be fixed soon?
Fixed, see #166510.
This report targets the FC3 or FC4 products, which have now been EOL'd.
Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?
Done. I still see this bug in FC6. None of my logs have rotated since Apr 06,
due to this bug.
test it, please.
Have run into what looks like this bug in RHEL-5 also. Should I open a new bug or switch this to RHEL-5?