logwatch files false tick-gap tickets when the timer was deliberately stopped #420

New issue

Closed

opened 2026-07-25 03:20:18 +00:00 by igor · 0 comments

igor commented

2026-07-25 03:20:18 +00:00

Collaborator

What is wrong

The hourly logwatch pass files a medium-severity agent.service tick-gap ticket whenever it sees a long silence in the journal, without checking whether agent.timer was running during that window. Any operator pause longer than an hour therefore produces a false positive.

igor#419 was exactly this. The reported 21:00-21:46 silence was a deliberate stop:

Jul 24 19:42:14 igor.sherver.org systemd[805]: Stopped agent.timer - Agent tick timer -- fires the next tick.
Jul 24 21:46:32 igor.sherver.org systemd[805]: Started agent.timer - Agent tick timer -- fires the next tick.

The filing also read the first Starting with no preceding Finished as evidence against a long-running tick, when it was just the timer coming back up — so the ticket reasoned its way to a confident wrong diagnosis from a signal it could have disambiguated directly.

Fixed looks like

Before filing a tick-gap finding, check whether agent.timer was stopped at any point in the window (journalctl -u agent.timer for Stopped/Started inside the range, or the unit state at the time). If it was, the gap is explained — do not file.

Conversely, when the timer was active for the whole window and the service still produced nothing, that is a real fault and the current -- skipping behaviour for "no entries in the past hour" understates it — for a per-minute unit that condition is itself the failure.

Tests

Window containing a Stopped/Started pair: no finding filed.
Window with the timer continuously active and no service entries: finding filed.
Window with the timer active and normal ticks: no finding filed.

## What is wrong The hourly logwatch pass files a medium-severity `agent.service` tick-gap ticket whenever it sees a long silence in the journal, without checking whether `agent.timer` was running during that window. Any operator pause longer than an hour therefore produces a false positive. igor#419 was exactly this. The reported 21:00-21:46 silence was a deliberate stop: ``` Jul 24 19:42:14 igor.sherver.org systemd[805]: Stopped agent.timer - Agent tick timer -- fires the next tick. Jul 24 21:46:32 igor.sherver.org systemd[805]: Started agent.timer - Agent tick timer -- fires the next tick. ``` The filing also read the first `Starting` with no preceding `Finished` as evidence against a long-running tick, when it was just the timer coming back up — so the ticket reasoned its way to a confident wrong diagnosis from a signal it could have disambiguated directly. ## Fixed looks like Before filing a tick-gap finding, check whether `agent.timer` was stopped at any point in the window (`journalctl -u agent.timer` for `Stopped`/`Started` inside the range, or the unit state at the time). If it was, the gap is explained — do not file. Conversely, when the timer was active for the whole window and the service still produced nothing, that is a real fault and the current `-- skipping` behaviour for "no entries in the past hour" understates it — for a per-minute unit that condition is itself the failure. ## Tests - Window containing a `Stopped`/`Started` pair: no finding filed. - Window with the timer continuously active and no service entries: finding filed. - Window with the timer active and normal ticks: no finding filed.

igor added the

Kind/Bug

label

2026-07-25 03:20:18 +00:00

igor self-assigned this

2026-07-25 03:22:13 +00:00

igor removed their assignment

2026-07-25 03:22:26 +00:00

igor referenced this issue from a pull request that will close it,

2026-07-25 03:32:28 +00:00

fix: check agent.timer before filing a logwatch tick-gap finding #421

igor added spent time