I keep getting these messages logged, when under high load.
This patch should clean that up.

commit 72661acccafa519fcb48a6a756e5c35d96e7511d
Author: Cristian Ionescu-Idbohrn <cristian.ionescu-idbohrn@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.

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.

I can also confirm that the patch fails to work, at least on my machine.

I still get daily cron emails about the kill command in that cleanup
function.

Francois

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

thanks

the patch/recipe below is still needed.

can pick up post bookworm