Bug 447022 - Logrotate doesn't rotate logs if /var/lib/logrotate.status is corrupted
Logrotate doesn't rotate logs if /var/lib/logrotate.status is corrupted
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: logrotate (Show other bugs)
All Linux
low Severity medium
: rc
: ---
Assigned To: Tomas Smetana
Depends On: 1321980
Blocks: 483734
  Show dependency treegraph
Reported: 2008-05-16 20:45 EDT by Filipe Brandenburger
Modified: 2016-06-28 10:43 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 483734 1321980 (view as bug list)
Last Closed: 2008-09-17 13:27:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Filipe Brandenburger 2008-05-16 20:45:53 EDT
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):


How reproducible:


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 {
    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:

Comment 1 Tomas Smetana 2008-05-21 02:12:49 EDT
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.
Comment 2 Filipe Brandenburger 2008-05-21 20:04:27 EDT

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.
Comment 3 Tomas Smetana 2008-05-22 02:00:10 EDT
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.
Comment 4 Cedric Porte 2008-06-20 10:24:09 EDT
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.
Comment 5 RHEL Product and Program Management 2008-07-21 19:02:25 EDT
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 "?".
Comment 12 errata-xmlrpc 2008-09-17 13:27:37 EDT
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.

Comment 13 Kamil Dudka 2016-06-28 10:18:43 EDT
(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:


... which caused a regression in RHEL-7: bug #1321980

Note You need to log in before you can comment on or make changes to this bug.