On Tue, Apr 30, 2013 at 12:12:56PM -0400, Joern Engel wrote: > Bug occurred with 3.7.8-6ubuntu3.1, but is present in Debian and all > upstream versions up to and including 3.8.4.
... > On -ENOSPC the state file is truncated, usually with a partial line at > the end. Future logrotate runs will use the state file, but fail to > write it with > "error: could not read state file, will not attempt to write into > it" > I suspect the only sane real fix is to get rid of the state file > for the dateext case. Glob for "logfile-20130430*", or maybe > "logfile-20130430" and "logfile-20130430.gz" and use that to decide > whether to rotate or not. Parsing filenames is not feasible. The dateformat can be anything the sysadmin specifies, and can vary from logfile to logfile. I'd be inclined to say that on ENOSPC on /var/lib, all bets are off. Things will stop working (eg. dpkg). The best you can hope for is for an automatic email to alert the sysadmin about the problem. Your suggested write/rename-or-fail-with-big-error is strategy is possible, and looks to me as a less worse solution. Using dateext is no worse (and no better) than the default in this case. Using file datestamps as a rotation criterion fails badly when the system time has been set to the wrong value at some point in the past. The alternative (and ultimately safest against log file data loss) is to delete the status file completely if it fails writing, and hence reset all the rotation intervals to their default. Unorthodox, yes, confusing, yes, but absolutely the least likely to cause data loss (except perhaps from allowing /var/log to run out of space too, which, if /var/lib and /var/log are on the same filesystem, has already happened). -- Paul Martin <p...@debian.org> -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
