Bug 276023 - security/logcheck: patch crontab to avoid duplicates
Summary: security/logcheck: patch crontab to avoid duplicates
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Yasuhiro Kimura
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-12-30 14:35 UTC by Dan Langille
Modified: 2024-02-11 04:10 UTC (History)
0 users

See Also:
yasu: maintainer-feedback+


Attachments
add patch to crontab (867 bytes, patch)
2023-12-30 14:35 UTC, Dan Langille
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dan Langille freebsd_committer freebsd_triage 2023-12-30 14:35:36 UTC
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
Comment 1 Yasuhiro Kimura freebsd_committer freebsd_triage 2024-02-10 03:55:21 UTC
(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?
Comment 2 Dan Langille freebsd_committer freebsd_triage 2024-02-10 12:41:26 UTC
(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.
Comment 3 commit-hook freebsd_committer freebsd_triage 2024-02-11 04:09:36 UTC
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(-)
Comment 4 Yasuhiro Kimura freebsd_committer freebsd_triage 2024-02-11 04:10:58 UTC
Committed with change to @reboot line. Thanks!