+++ 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.
Sigh, assuming, EL6 version is hit by the error too. I'll take a look on how to change this.
*** Bug 730824 has been marked as a duplicate of this bug. ***
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?
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
Thank you for your feedback. An update containing a fix will follow soon.
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
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
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).
(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.
updated builds in updates-testing
(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.
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.
(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.
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.
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.