Bug 705822

Summary:	run-parts needs the --list parameter (or logcheck needs a workaround)
Product:	[Fedora] Fedora EPEL	Reporter:	Till Maas <opensource>
Component:	logcheck	Assignee:	Matthias Runge <mrunge>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	el5	CC:	chris, cummings, glshank, mrunge, opensource
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	logcheck-1.3.13-5.el6	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	643130	Environment:
Last Closed:	2011-09-24 21:56:01 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	643130
Bug Blocks:

Description Till Maas 2011-05-18 15:31:54 UTC

+++ This bug was initially created as a clone of 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.

--- Additional comment from mrunge on 2010-10-14 20:21:21 CEST ---

I see the problem. Interestingly, logcheck works for me just a while now without any problems.

Imho there are two possible solutions:
1. Contact run-parts-maintainer to implement the --list option (like in debian)
2. Implement a workaround (and patch run-parts out)

I'd prefer the first option and will contact crontabs-maintainer to discuss a solution.




Using run-parts from Fedora with the "--list" parameter added to the invocation within logcheck fixes this problem in EPEL logcheck.

Comment 1 Matthias Runge 2011-05-19 06:59:26 UTC

Sigh,

assuming, EL6 version is hit by the error too. I'll take a look on how to change this.

Comment 2 Matthias Runge 2011-08-16 06:38:52 UTC

*** Bug 730824 has been marked as a duplicate of this bug. ***

Comment 3 Matthias Runge 2011-08-16 06:46:41 UTC

Ok, I saw the hint of substituting run-parts with plain 'ls'. I think, it'll be better to change it to someting like

find . -maxdepth 1 -type f ! -name "*.spec" ! -name "*.old" ! -name "*.rpmnew" ! -name "*.rpmsave"

can you confirm this?

Comment 4 glshank 2011-08-16 15:42:08 UTC

I had to change 'find .' to 'find "$dir"' and then it worked. Final result looks like this:

   for rulefile in $(find "$dir" -maxdepth 1 -type f ! -name "*.spec" ! -name "*.old" ! -name "*.rpmnew" ! -name "*.rpmsave"); do

I might even add '! -name "*.rpmorig"' to the list.

Thanks,
Greg

Comment 5 Matthias Runge 2011-08-17 12:19:15 UTC

Thank you for your feedback. An update containing a fix will follow soon.

Comment 6 Fedora Update System 2011-08-17 12:23:41 UTC

logcheck-1.3.13-4.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/logcheck-1.3.13-4.el5

Comment 7 Fedora Update System 2011-08-17 12:24:57 UTC

logcheck-1.3.13-4.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/logcheck-1.3.13-4.el6

Comment 8 Fedora Update System 2011-08-19 16:27:28 UTC

Package logcheck-1.3.13-4.el5:
* should fix your issue,
* was pushed to the Fedora EPEL 5 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing logcheck-1.3.13-4.el5'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/logcheck-1.3.13-4.el5
then log in and leave karma (feedback).

Comment 9 Till Maas 2011-08-19 16:38:00 UTC

(In reply to comment #4)
> I had to change 'find .' to 'find "$dir"' and then it worked. Final result
> looks like this:
> 
>    for rulefile in $(find "$dir" -maxdepth 1 -type f ! -name "*.spec" ! -name
> "*.old" ! -name "*.rpmnew" ! -name "*.rpmsave"); do
> 
> I might even add '! -name "*.rpmorig"' to the list.

Please also ignore files like "*~", "*,", "*.swp", und "*.cfsaved", because they are ignored by run-parts on Fedora 15, too. It might even be a good idea to ignore all hidden files.

Comment 10 Matthias Runge 2011-08-26 15:04:46 UTC

updated builds in updates-testing

Comment 11 Till Maas 2011-09-07 12:55:11 UTC

(In reply to comment #10)
> updated builds in updates-testing

You need to request that the updated update in Bodhi is pushed to testing. Changing the build reseted the request afaics.

Also it would be better to prepare a patch instead of using sed to make the build fail in case upstream changes the code for sed not to work anymore. And another improvement would be to also ignore all hidden files, i.e. ".*" and the comment in the spec is wrong for the sed line.

Comment 12 Matthias Runge 2011-09-07 14:57:30 UTC

I thought, those builds get automagically into testing when I request testing....

The spec needs a cleanup. I'll prepare a patch, including hidden files.

Comment 13 Till Maas 2011-09-07 15:06:47 UTC

(In reply to comment #12)
> I thought, those builds get automagically into testing when I request
> testing....

If you edit a Bodhi update e.g. by changing the attached builds, the reqest to push it to testing is reset iirc. Therefore you need to request testing again after changing the included builds.

Comment 14 Fedora Update System 2011-09-24 21:55:44 UTC

logcheck-1.3.13-5.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 15 Fedora Update System 2011-09-24 21:58:01 UTC

logcheck-1.3.13-5.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.