Bug 166509 - Logrotate should be more forgiveable with its statefile
Logrotate should be more forgiveable with its statefile
Product: Fedora
Classification: Fedora
Component: logrotate (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Vrabec
Depends On:
  Show dependency treegraph
Reported: 2005-08-22 13:44 EDT by Filipe Brandenburger
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-04-02 07:52:50 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 2005-08-22 13:44:02 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc3 Firefox/1.0.6

Description of problem:
Logrotate doesn't forgive errors on its statefile, and *STOPS* rotating all logs if something happens with its file. This requires manual intervention (that is, removing the file), but it's kind of stupid, because logrotate itself could ignore the file (or better yet, use only the entries it recognizes) and avoid having the administrator to intervene...

I had this problem in a host, I guess it hang'd just after a logrotate happened, and the state file ended up like this:

# cat /var/lib/logrotate.status
logrotate state -- version 2
"/var/log/apache/access_log" 2005-8-6
"/var/log/apache/error_log" 2005-8-9
"/var/log/cron" 2005-8-2
"/var/log/wtmp" 2005-8-2
ar/log/wtmp" 2005-8-11

Notice the garbage on the last line... The result was that when I run logrotate, the output was this:

# /usr/sbin/logrotate /etc/logrotate.conf
error: bad line 29 in state file /var/lib/logrotate.status

I actually got it when I saw the space on the host's disk growing. I promptly removed the file, and everything started working again (yeah, some collateral effect because daily/weekly didn't work right, but anyway, better than not functioning at all!).

Logrotate could even do a better job, because it could actually use the lines it recognizes, only ignoring (and maybe printing a warning about it) the other lines.

I believe the problem was because logrotate opens the statefile for writing and writes the contents on the file, that changes the content and possibly the size of the file, but as these information are kept separate (the size is on the inode), the corruption probably was due to a hang after the content was written from the cache to disk, but the i-node not yet (or the inverse). This situation would be more unusual to happen if the content of the statefile was written to a temporary file which would be then rename'd to the statefile. Anyway, this has other implications, so I'm not asking for this to be done, but I guess it could be considered.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Open the logrotate.status file with an editor
2. Append some text like ``ar/log/wtmp" 2005-8-11'' to the last line.
3. Run logrotate.

Actual Results:  The following error line:

error: bad line 29 in state file /var/lib/logrotate.status

And no logs were rotated!!! I'm not complaining about getting an error, I'm complaining about log rotation stopping working.

Expected Results:  Log rotation should have worked, and a warning about the file format should be issued. If necessary, logrotate could assume the file contents were empty, or it could also use the status lines it could understand.

Additional info:
Comment 1 Peter Vrabec 2007-04-02 07:52:50 EDT
I'm not fixing it, state file should be always OK.

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