Created attachment 247359 [details] add patch to crontab In my 24 years of using logcheck, this problem has only arisen a few times. Sometimes, the log can grow very large. This happens when the host is heavily loaded. Under those circumstances, logcheck does not complete before the next crontab starts. The attached patch introduces a /usr/bin/lockf call to avoid duplicate concurrent instances of logcheck. I've been running this within a dev instance of FreshPorts for about a week now. If this change seems to be generic, I hope it is helpful
(In reply to Dan Langille from comment #0) Hi Dan, Thanks for patch. Let me assume following situation. [12:02] * System works fine. * Log size increased modestly since an hours ago. * Logcheck is invoked from crontab and finishes soon. [12:10] * Something gets wrong. * Log size start increasing rapidly [12:50] * Administrator notices the trouble and starts investgating. [12:55] * He dicides to reboot system to fix the troble. [12:58] * The system has been rebooted. * It gets back fine now. * Log size has already increased incredibly since 12:02 * Logcheck is invoked from crontab and keeps working. [13:02] * Logcheck is invoked from crontab At 13:02, it is very likely that logcheck instance invoked at 12:58 is still working. And it means two instances works concurrently. So should lockf(1) also be used in '@reboot' line?
(In reply to Yasuhiro Kimura from comment #1) Oh I see what you mean now. Yes, I agree, reboot needs lockf(1) too. Good point.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=4d161fff033445025c42bd05f0eba6aebed15563 commit 4d161fff033445025c42bd05f0eba6aebed15563 Author: Dan Langille <dvl@FreeBSD.org> AuthorDate: 2024-02-11 02:19:54 +0000 Commit: Yasuhiro Kimura <yasu@FreeBSD.org> CommitDate: 2024-02-11 04:06:24 +0000 security/logcheck: Add patch to change crontab entry When the host is heavily loaded, the log files can grow incredibly and one logcheck invocation may not complete before it is invoked next time. This commit add patch to change crontab entries so it uses lockf(1) to avoid multiple invocation of logcheck under such situation as above. PR: 276023 security/logcheck/Makefile | 2 +- security/logcheck/files/patch-debian_logcheck.cron.d | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-)
Committed with change to @reboot line. Thanks!
Today another use case occurred. No action required. I am posting to document. If the host reboots at about 2 past the hour, you can get the @reboot running and then the cron job for "2 * * * *" starts up. That just happened here, and lockf worked as expected. Thank you. From: Cron Daemon <logcheck@mysql01.int.unixathome.org> To: root Subject: Cron <logcheck@mysql01> if [ -x /usr/local/sbin/logcheck ]; then /usr/bin/lockf -t 0 /tmp/.logcheck nice -n10 /usr/local/sbin/logcheck; fi X-Cron-Env: <PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin> X-Cron-Env: <MAILTO=root> X-Cron-Env: <SHELL=/bin/sh> X-Cron-Env: <LOGNAME=logcheck> X-Cron-Env: <USER=logcheck> Date: Wed, 19 Jun 2024 17:02:00 +0000 Message-Id: <66730f08.9e00.39ca95f9@mysql01.int.unixathome.org> lockf: /tmp/.logcheck: already locked