Bug#657641: /usr/sbin/logcheck: line 100: kill: (31667) - No such process
Control: tags -1 + confirmed Control retitle -1 improve locking mechanism thanks the patch/recipe below is still needed. can pick up post bookworm On Thu, 28 Sep 2017 09:56:42 +0200 matthijs wrote: > Turns out the locking is actually ineffective ( > Doing some tests shows that the cause of this problem are these lines [1]: > > lockfile-create --retry 1 "$LOCKFILE" > /dev/null 2>&1 > > if [ $? -eq 1 ]; then > # Locked, error and quit > > This only treats an exit code of 1 as an error, while lockfile-create > actually returns "4" in this case [2]. Changing this to `$? -ne 0`, or > even more compact: > > if ! lockfile-create --retry 1 "$LOCKFILE" > /dev/null 2>&1; then > > will fix this problem.
Bug#657641: /usr/sbin/logcheck: line 100: kill: (31667) - No such process
Package: logcheck Version: 1.3.18 Followup-For: Bug #657641 Hi, this problem still exists in current versions, I just ran into it. It seems to occur when there are a large number of log lines to process, so that the previous run of logcheck is not complete when the next one is started. I just caught a case of three logchecks running in parallel, which is really what this locking is supposed to prevent. Turns out the locking is actually ineffective (see below), allowing multiple logcheck runs to run at the same time. Once the first one finishes, it kills its own lockfile-touch and removes the lockfile. I couldn't find any docs about how lockfile-touch behaves when its lockfile is deleted, but the source confirms that it exits with an error code. Due to this, when the second logcheck run completes, its lockfile-touch process will have quit, leading to the kill error message. Doing some tests shows that the cause of this problem are these lines [1]: lockfile-create --retry 1 "$LOCKFILE" > /dev/null 2>&1 if [ $? -eq 1 ]; then # Locked, error and quit This only treats an exit code of 1 as an error, while lockfile-create actually returns "4" in this case [2]. Changing this to `$? -ne 0`, or even more compact: if ! lockfile-create --retry 1 "$LOCKFILE" > /dev/null 2>&1; then will fix this problem. Gr. Matthijs [1]: https://anonscm.debian.org/cgit/logcheck/logcheck.git/tree/src/logcheck#n633 [2]: https://github.com/miquels/liblockfile/blob/master/lockfile.h#L31-L38
Bug#657641: /usr/sbin/logcheck: line 100: kill: (31667) - No such process
Package: logcheck Version: 1.3.15 Followup-For: Bug #657641 Dear Maintainer, I applied the patch as detailed here, but there is no change in the situation even after rebooting, I am still getting lots of messages like this '/usr/sbin/logcheck: line 100: kill: (26603) - No such process' . This is how I installed the patch. if [ -n $LOCK ]; then debug cleanup: Killing lockfile-touch - $LOCK kill $LOCK unset LOCK fi Replace the third line with kill -0 $LOCK kill $LOCK unset LOCK Thank you Sharon. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages logcheck depends on: ii adduser3.113+nmu3 ii cron 3.0pl1-124 ii exim4-daemon-light [mail-transport-agent] 4.80-6 ii lockfile-progs 0.1.17 ii logtail1.3.15 ii mime-construct 1.11 ii rsyslog [system-log-daemon]5.8.11-2 Versions of packages logcheck recommends: ii logcheck-database 1.3.15 Versions of packages logcheck suggests: ii syslog-summary 1.14-2 -- Configuration Files: /etc/logcheck/logcheck.conf [Errno 13] Permission denied: u'/etc/logcheck/logcheck.conf' /etc/logcheck/logcheck.logfiles [Errno 13] Permission denied: u'/etc/logcheck/logcheck.logfiles' -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657641: /usr/sbin/logcheck: line 100: kill: (31667) - No such process
Package: logcheck
Version: 1.3.14
Severity: normal
Tags: patch
I keep getting these messages logged, when under high load.
This patch should clean that up.
commit 72661acccafa519fcb48a6a756e5c35d96e7511d
Author: Cristian Ionescu-Idbohrn cristian.ionescu-idbo...@axis.com
Date: Fri Jan 27 16:08:33 2012 +0100
Workaround for error:
/usr/sbin/logcheck: line 100: kill: (31667) - No such process
diff --git a/logcheck b/logcheck
index 5878795..91125cd 100755
--- a/logcheck
+++ b/logcheck
@@ -97,7 +97,7 @@ cleanup() {
if [ -n $LOCK ]; then
debug cleanup: Killing lockfile-touch - $LOCK
- kill $LOCK unset LOCK
+ kill -0 $LOCK kill $LOCK unset LOCK
fi
if [ -f $LOCKFILE.lock ]; then
The script would surely benefit (efficiency wise) from a thorough
cleanup, IMO.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages logcheck depends on:
ii adduser 3.113
ii cron3.0pl1-120
ii lockfile-progs 0.1.16
ii logtail 1.3.14
ii mime-construct 1.11
ii postfix [mail-transport-agent] 2.8.7-1
ii rsyslog [system-log-daemon] 5.8.6-1
Versions of packages logcheck recommends:
ii logcheck-database 1.3.14
Versions of packages logcheck suggests:
ii syslog-summary 1.14-2
-- Configuration Files:
/etc/logcheck/logcheck.conf [Errno 13] Permission denied:
u'/etc/logcheck/logcheck.conf'
/etc/logcheck/logcheck.logfiles [Errno 13] Permission denied:
u'/etc/logcheck/logcheck.logfiles'
-- debconf information:
logcheck/changes:
* logcheck/install-note:
Cheers,
--
Cristian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
