Werk #19539: Relay update flow no longer trips the systemd start rate limit
| Component | Relay | ||||
| Title | Relay update flow no longer trips the systemd start rate limit | ||||
| Date | Jun 23, 2026 | ||||
| Level | Prominent Change | ||||
| Class | Bug Fix | ||||
| Compatibility | Compatible - no manual interaction needed | ||||
| Checkmk versions & editions |
|
When a relay's version lagged behind its site, its update could get stuck and never complete on its own, so the relay stayed on the old version until someone intervened on the relay host.
With this fix, the relay retries the update on a slower, steady cadence, so a transient failure now recovers by itself.
Are you affected?
You are affected if a relay failed to update and its update never recovered. On the relay host, the update unit then sits in a failed state with the message "start request repeated too quickly".
To recover such a relay, clear the failed state and restart the watcher on the affected relay host:
sudo systemctl reset-failed checkmk_relay-update-manager.service checkmk_relay-update-manager.path
sudo systemctl restart checkmk_relay-update-manager.path
You can confirm the recovery with:
systemctl status checkmk_relay-update-manager.path checkmk_relay-update-manager.service --no-pager
Technical background
Previously, when a relay's version lagged behind its site, the relay rewrote its update trigger file on every poll cycle -- roughly once a second. Each write asks systemd to start the update unit, so a run of failed updates could hit systemd's start rate limit and leave the update unit permanently stuck.
The relay now still checks for version changes every second, but triggers an update at most once a minute. Updates keep retrying on that slower cadence without overwhelming systemd.