Bug 643130

chris@chris....uk reported the following problem:

Thanks very much for adding logcheck to the repository - great tool.  But it
doesn't seem to be working at all: it's not filtering any entries out on my
system.

I've tested using log messages from a few daemons with /usr/bin/logcheck-test,
and the ignore rules are matching correctly, but a run of logcheck then spews
out all those log messages without filtering any out.

Here's what I think is happening: logcheck uses /usr/bin/run-parts to pick up
the filter rule files from subdirectories of /etc/logcheck.  run-parts looks
for executables, and runs them.  But that's not what logcheck wants it to do -
logcheck wants it to spit out the names of matching files, not actually execute
them.

The Debian version of run-parts has a --list parameter, which does exactly
this.  When the logcheck package has been ported across to Fedora, the --list
parameter has been removed from the invocation of run-parts (because our
version of run-parts doesn't have that parameter), but that simply results in
run-parts producing no output.  Which means that logcheck thinks it has no
filter rule files.  Which means no log messages ever get filtered out.

I'm surprised that this is the case, because the package should never have been
pushed to stable with such a fundamental bug in it.  But I'm fairly sure that's
what's going on (on my system, at least - Fedora 13 with
logcheck-1.3.13-2.fc13.noarch and crontabs-1.10-32.fc13.noarch).
-------
In confirmation of the above: simply replacing the invocation of run-parts with
/bin/ls in the cleanrules() function of logcheck fixes the problem.

We don't want to do this, because it loses the benefits of run-parts (ignoring
.rpmsave files, etc.) - but it does demonstrate that that's where the problem
is.