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):
logrotate-3.7.1-2

How reproducible:
Always

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: