Bug 447022 - Logrotate doesn't rotate logs if /var/lib/logrotate.status is corrupted
Summary: Logrotate doesn't rotate logs if /var/lib/logrotate.status is corrupted
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: logrotate
Version: 5.1
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Tomas Smetana
QA Contact:
URL:
Whiteboard:
Depends On: 1321980
Blocks: 483734
TreeView+ depends on / blocked
 
Reported: 2008-05-17 00:45 UTC by Filipe Brandenburger
Modified: 2018-09-12 07:24 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 483734 1321980 (view as bug list)
Environment:
Last Closed: 2008-09-17 17:27:37 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2008:0881 0 normal SHIPPED_LIVE logrotate bug fix update 2008-09-17 17:27:22 UTC

Description Filipe Brandenburger 2008-05-17 00:45:53 UTC
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

Comment 1 Tomas Smetana 2008-05-21 06:12:49 UTC
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-22 00:04:27 UTC
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.


Comment 3 Tomas Smetana 2008-05-22 06:00:10 UTC
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 14:24:09 UTC
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 Program Management 2008-07-21 23:02:25 UTC
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 17:27:37 UTC
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

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

Comment 14 richlv 2018-09-12 06:22:53 UTC
The referenced bug #1321980 is not accessible - can it please be made available?

Comment 15 Kamil Dudka 2018-09-12 07:24:14 UTC
(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


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