Description of problem: Logrotate doesn't rotate logs if /var/lib/logrotate.status is corrupted. It gives you an error message and terminates, without rotating the logs. This issue got me once when, after a reboot, /var/lib/logrotate.status became corrupted. The machine stopped to rotate the logs, but as it was a very busy mail server, I started having issues with the machine and it took me quite some time to find out that it was related to the fact that the logs were not rotated and that logrotate was not working because that file was corrupted. As for some machines logrotate is quite vital, and as the issue will not fix itself without administrator intervention, I believe it would be more useful if the default behaviour would be to recreate the corrupt file (since obviously that's the only sensible thing to do) and force log rotation anyway. Version-Release number of selected component (if applicable): logrotate-3.7.4-8 How reproducible: Always. Steps to Reproduce: 1. Take a log that rotates based on size. For instance I'm using yum.log, which is configured to rotate with "size 30k" here. # cat /etc/logrotate.d/yum /var/log/yum.log { missingok notifempty size 30k create 0600 root root } 2. Fill the log with more than 30k of data # ls -l /var/log/yum.log -rw------- 1 root root 49825 May 16 20:40 /var/log/yum.log 3. Corrupt the contents of logrotate.status # dd if=/dev/random bs=1k count=1 of=/var/lib/logrotate.status 0+1 records in 0+1 records out 128 bytes (128 B) copied, 0.000158 seconds, 810 kB/s 4. Run logrotate # logrotate /etc/logrotate.conf error: bad top line in state file /var/lib/logrotate.status 5. Check that the log didn't rotate # ls -l /var/log/yum.log -rw------- 1 root root 49825 May 16 20:40 /var/log/yum.log 6. (Admin intervention) Remove logrotate.status # rm -fv /var/lib/logrotate.status removed `/var/lib/logrotate.status' 7. Run logrotate again # logrotate /etc/logrotate.conf # (no errors this time) 8. Check that the log rotated # ls -l /var/log/yum.log /var/log/yum.log.1 -rw------- 1 root root 0 May 16 20:42 /var/log/yum.log -rw------- 1 root root 49825 May 16 20:40 /var/log/yum.log.1 Actual results: error: bad top line in state file /var/lib/logrotate.status Logs are not rotated Expected results: Logs should be rotated anyway. The file logrotate.status should be removed or renamed. The program should probably issue an error message anyway, so that a cautious admin could go and check everything. Logs that rotate periodically (daily, weekly, monthly, yearly) should probably be rotated at that time, if the status file is deemed corrupt. I consider that rotating the logs is a safer measure than not rotating them. I see the harm in rotating too much is smaller than the harm in not rotating them at all. Additional info: N/A
The status file is not supposed to be edited by the user and any corruption in it is considered to be a serious error. I can't imagine a situation when this could be solved without a manual intervention that should involve also re-running logrotate.
Agreed. However, the default action of logrotate, which is "stop rotating all logs" when the file gets corrupted, does not help at all. It would be more helpful to discard the contents of the file, force the logs to rotate (it's the safest thing to do) and recreate the file from that point. That would allow the problem to be fixed (the only way it can be fixed really) without an administrator intervention. Otherwise, it's more administrative job. Not to mention that if the admin is not watching closely, this is a time bomb ready to blow at any time. In some machines, if the logs stop rotating, they can easily fill the disk of the machine in a few hours.
You're right that stopping to rotate the files is probably not the best idea -- issuing an error should be enough. However I'm afraid to touch a file that got magically corrupted -- it may cause even more damage. I'll try to change the behaviour in case of status file error in the upstream version and then backport to RHEL.
Same error on my side, i performed a rm -rf /var/lib/logrotate.status, then a logrotate -f /etc/logrotate.d/syslog. /var/lib/logrotate.status has been created after this and logrotate work correctly now.
This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the current Red Hat Enterprise Linux release. If you would like this request to be reviewed for the next minor release, ask your support representative to set the next rhel-x.y flag to "?".
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2008-0881.html
(In reply to Tomas Smetana from comment #3) > I'll try to change the behaviour in case of status file error in the upstream > version and then backport to RHEL. For your information, the upstream commit has been reverted: https://github.com/logrotate/logrotate/commit/r3-8-5~20 ... which caused a regression in RHEL-7: bug #1321980
The referenced bug #1321980 is not accessible - can it please be made available?
(In reply to richlv from comment #14) > The referenced bug #1321980 is not accessible There is nothing really interesting on the mentioned bug. You can follow progress on a similar RHEL-7 bug here: bug #1374550 There is also an upstream patch to implement recovery from a corrupted state file but there is no plan to backport it to RHEL-7 yet: https://github.com/logrotate/logrotate/commit/b9d82003