Werk #19803: systemd_units: Fix false 'activating/reloading for X' alerts
| Component | Checks & agents | ||||||
| Title | systemd_units: Fix false 'activating/reloading for X' alerts | ||||||
| Date | May 4, 2026 | ||||||
| Level | Trivial Change | ||||||
| Class | Bug Fix | ||||||
| Compatibility | Compatible - no manual interaction needed | ||||||
| Checkmk versions & editions |
|
Previously, the Systemd Service Summary check on Linux hosts could emit a spurious WARN or CRIT of the form
Service 'X' activating for: Y minutes (warn/crit at A/B)
or
Service 'X' reloading for: Y minutes (warn/crit at A/B)
on services that had in fact finished within seconds.
Affected services were typically timer-driven, e.g. mlocate.service, apt-daily.service, or phpsessionclean.service, or support reloading.
The Linux agent emits the systemd state via two independent systemctl invocations.
If a timer fired between them, the parser merged the active state from the second snapshot with a duration from the first, producing the bogus alert.
The parser now sources the active state and the duration from the same snapshot, so the inconsistent merge — and the resulting false alerts for "activating" — no longer occur.
When a service is reloaded, the timestamp and the duration in the systemctl output continue to reflect the original activation, not the start of the reload.
So, a service that has been running for two days and is currently reloading will still show
Active: reloading (reload) since … ; 2 days ago"
even if the reload itself only started seconds ago.
In future versions of Checkmk this can be addressed, but the required changes are too extensive for a released version.
Hence, users observing false alerts for "reloading" have the option of a workaround:
Unset the Tolerance period for 'reloading' state to prevent the service from going to WARN or CRIT.
Note: This will also silence any alert about services actually stuck in a reloading state.