Logcheck devel - Oct 2007 - Buggy handling of fresh system install at logcheck's plugged 10-dtr code

I installed Ubuntu Gutsy with logcheck 1.2.61, logtail 1.2.61. Around 6 
AM this morning, logcheck suddenly started failing, claiming that there 
is a problem with logtail or output redirection.

I investigated the issue. When the system is fresh and the logrotates 
are run for the first time, no files matching a pattern like 
"$filename.1.gz" at /var/log exists. However, the savelog rotation 
handler presumes the existence of such a file through 
mtime("$filename.1.gz"), which dies on failure. The die seems OK in 
principle; what is not OK is implicitly assuming that .1.gz must exist 
if .0 exists.

Here's the fixed 10-savelog.dtr.

sub {
  my ($filename) = @_;
  my $rotated_filename="";
  if (-e "$filename.0"
    && (! -e "$filename.1.gz"
        || mtime("$filename.0") >
mtime("$filename.1.gz"))
  ) {
    # assume the log is rotated by savelog(8)
    # syslog-ng leaves old files here
    $rotated_filename="$filename.0";
  }
  return $rotated_filename;
}

If this bug is not fixed, the logcheck crashes, complaining about a 
problem with logtail. (logcheck's STDERR redirect hides the error.)


As a design issue, I believe the current pluggable logrotate detection 
code is a bit foolish. Since every result from these plugged mechanisms 
is going to be matched against the inode of the old log file, and 
rejected if it does not match, it could make a lot more sense to simply 
scan the whole directory looking for the inode number instead of trying 
to heuristically guess what kind of log rotation is taking place.

In that case, the old file would be found by code like:

my ($rotated_file) = grep { inode($_) == $inode_from_state_file } 
<$directory/*>

and no pluggable mechanisms for guessing rotated filenames would be 
necessary.

-- 
Antti