Created attachment 951758 [details] Output of sudo -u logcheck /usr/sbin/logcheck with debugging enabled Description of problem: Logcheck generates an error each time it runs, e.g.: /usr/sbin/logcheck: line 100: kill: (5430) - No such process This then gets sent every hour by logcheck itself. I have traced it back to a failure to read /var/log/messages, which is included in /etc/logcheck/logcheck.logfiles on install. So the direct cause is that the permissions of the logfile here is not set by the installer to allow the adm group (of which logcheck is a member) to read the file. I have made the fix and it resolves the immediate issue. I would also suggest: - the "unable to read" error should be visible to the administrator - the knock-on error "no such process" should not Version-Release number of selected component (if applicable): logcheck-1.3.13-5.el6.noarch How reproducible: Reproduced on 5 servers installed identically with a basic install plus logcheck from EPEL. Steps to Reproduce: 1. Check /var/log/mesages permissions, default assumed to be 0600 root:root 2. Install logcheck 3. Check /var/log/messages permissions again - I find it to be 0600 root:root 4. Run logcheck: sudo -u logcheck /usr/sbin/logcheck Actual results: Logcheck runs, but emits an error each time, e.g.: /usr/sbin/logcheck: line 100: kill: (5430) - No such process The error is apparently preventing logcheck from reading /var/log/messages Expected results: There should be no error. /var/log/messages should be scanned. Errors when they do occur should reflect the actual problem. Additional info: Running logcheck with debug output is attached. Here is a snippet showing an error which is normally hidden: D: [1414583498] logoutput called with file: /var/log/messages D: [1414583498] Running /usr/sbin/logtail2 on /var/log/messages D: [1414583498] error: Killing lockfile-touch - 16879 D: [1414583498] error: Removing lockfile: /var/lock/logcheck/logcheck.lock D: [1414583498] Error: Could not run logtail or save output D: [1414583498] Sorting logs You can see logcheck failing to read /var/log/messages, then killing the lockfile-touch process. Later, the cleanup() function tries to do it again, but there is no such process any more: D: [1414583499] cleanup: Killing lockfile-touch - 16879 /usr/sbin/logcheck: line 100: kill: (16879) - No such process D: [1414583500] cleanup: Removing - /tmp/logcheck.TyHVZy Thanks for porting logcheck for RHEL!
Thank you for this write up. Sadly, it's a known issue and I could provide you only a workaround: edit /etc/logrotate.d/syslog and add: create 0640 root adm At least, changing acls in logrotate as well will make sure, the rights will stay that way. Otherwise logrotate will change them back once logrotate is run. Background: /var/log/messages is not owned by any package, thus one couldn't open a ticket against that component to request a change of acls. Not ideal though...
Thanks, noted. That needs to be done for /var/log/messages and /var/log/secure. by default. I suppose an alternative (for you the maintainer) might be to run logcheck and/or logtail as root, but that's not ideal either. Perhaps there is a solution involving sudo. I also wonder how Debian solves it... These are things I expect have been discussed elsewhere, in more depth, so I'll leave it at that. However, I would like make one final request: that the resulting error be made more transparent for administrators, so they know what to do immediately, and not think there is a bug somewhere. Likewise, it might be worth mentioning the above in the documentation, perhaps in a README.redhat file - looking in /usr/share/logcheck-[..]/ I don't see the topic mentioned. Besides, I had of course skipped this until now, assuming I knew what to do having installed it on Debian systems. I can't guarantee I'll find the time to contrbute patches for the above, but I may if encouraged with some feedback on the preferred way. Thanks!