logcheck-1.3.8 doesn't appear to work at all on a near-fresh install: int cron.hourly # su -s /bin/bash -c /usr/sbin/logcheck logcheck sort: open failed: /tmp/logcheck.7KJvHo/logoutput/*: No such file or directory int cron.hourly # ls -l /tmp total 19 drwxr-x--- 2 root wheel 1024 Jul 16 22:56 cpufreqd-JNg3gt/ drwx------ 2 valeo users 1024 Jul 16 21:57 gpg-KcEACX/ drwx------ 2 root root 12288 Jul 9 05:00 lost+found/ drwx------ 2 valeo users 1024 Jul 16 22:10 orbit-valeo/ drwx------ 2 valeo users 1024 Jul 16 21:58 pulse-RwKSB1FebW39/ drwx------ 2 valeo users 1024 Jul 16 21:57 ssh-FAGxbR6574/ -rw-r--r-- 1 root root 85 Jul 16 22:07 tsp-broker-list.txt -rw-r--r-- 1 root root 23 Jul 16 22:09 tsp-last-server.txt srwxr-xr-x 1 root root 0 Jul 16 22:57 wpa_ctrl_5479-1= I'll try and track this down, though I'm completely unfamiliar with this package, so perhaps a dev will fare better than I.
Created attachment 239097 [details, diff] Tweak the language in pkg_postinst() slightly. The language in pkg_postinst() could also do with tweaking...
Thanks for re-assigning this, Sebastian! I'd argue that a package in stable not working at all isn't exactly classed as "normal", but I'm not the one with bugedit privileges, so I'll leave that discussion for another day. ;)
I've changed the postinst message to link to our documentation, http://www.gentoo.org/doc/en/logcheck.xml . Could you check if following that guide will make logcheck work on your system? Please re-open and/or file further bugs in case of problems.
Thanks, but that guide covers things I've already done/tried. I have just now installed afresh from stage3 in a VM, updated the entire system ("emerge -uDN world") and installed logcheck-1.3.8. The results are the same.
Could you please run logcheck with LOGCHECKDEBUG=1 environment variable? Please make sure it is passed to the binary, you should see some additional debug output.
Are you sure about that? valeo@int ~ $ sudo su -s /bin/bash -c 'LOGCHECKDEBUG=1 /usr/sbin/logcheck' logcheck sort: open failed: /tmp/logcheck.4c9tvV/logoutput/*: No such file or directory I haven't got time to look into this any further today, so I'll attach {l,s}trace output when I next have a break, just in case that info is of any use.
Apologies for the delay, I've been ill for the best part of the last couple of weeks... anyhow, I'll look into this further today.
(In reply to comment #6) > Are you sure about that? > > valeo@int ~ $ sudo su -s /bin/bash -c 'LOGCHECKDEBUG=1 /usr/sbin/logcheck' > logcheck > sort: open failed: /tmp/logcheck.4c9tvV/logoutput/*: No such file or > directory Oh, sorry. I gave you the wrong command. :( This one works, checked on my system: su -s /bin/bash -c '/usr/sbin/logcheck -d' logcheck
(In reply to comment #8) > (In reply to comment #6) > > Are you sure about that? > > > > valeo@int ~ $ sudo su -s /bin/bash -c 'LOGCHECKDEBUG=1 /usr/sbin/logcheck' > > logcheck > > sort: open failed: /tmp/logcheck.4c9tvV/logoutput/*: No such file or > > directory > > Oh, sorry. I gave you the wrong command. :( > > This one works, checked on my system: > > su -s /bin/bash -c '/usr/sbin/logcheck -d' logcheck Ah ok. I ended up editing the logcheck script itself in the end, as it obviously wasn't honouring the environment. Anywho, after a quick look I've discovered why logcheck doesn't work OOTB: Gentoo (or rather syslog-ng and others) don't write to "/var/log/syslog" (it's of course "/var/log/messages") and logcheck doesn't check if any of the files in "/etc/logcheck/logcheck.logfiles" actually exist in the filesystem. There's seemingly a great deal of error checking not happening from a quick look at the script as well. I could perhaps create a couple of patches for the ebuild and the logcheck script that (a) inform the user that they will need to edit "/etc/logcheck/logcheck.logfiles" if the syslog they're using doesn't write to "/var/log/syslog" and (b) perform some basic error checking/reporting so future errors from logcheck aren't quite so illustrious. Or you could just close this bug, it's up to you. ;)
Just when I think this issue has been resolved, I start getting this: int logcheck # su -s /bin/bash -c /usr/sbin/logcheck logcheck /usr/sbin/logcheck: line 100: kill: (26685) - No such process I'm sorely tempted to go back to logsentry... Paweł, do you by any chance have a configuration file I could try? I've tried the ebuild-supplied one and my own and neither work. I'll attach mine in a sec in case there's something up there, although I doubt there is.
Created attachment 241167 [details] Slightly customised logcheck.conf
(In reply to comment #10) > Paweł, do you by any chance have a configuration file I could try? Your config file looks fine. Did you adjust /etc/logcheck/logcheck.logfiles? I'm going to update the logcheck guide, the current one is missing that information.
I did indeed adjust "logcheck.logfiles", however that made no difference. Stock configuration and my own both resulted in the above error (comment #10) from kill(1).
(In reply to comment #10) > Just when I think this issue has been resolved, I start getting this: > > int logcheck # su -s /bin/bash -c /usr/sbin/logcheck logcheck > /usr/sbin/logcheck: line 100: kill: (26685) - No such process This is from the below part of the script. Could you run with debug output and see what's the value of $LOCK? Is it possible that you have it defined in your environment and it confuses the script? # Carry out the clean up tasks cleanup() { if [ -n "$LOCK" ]; then debug "cleanup: Killing lockfile-touch - $LOCK" kill "$LOCK" && unset LOCK fi
