Calculate cumulative restart delay for a systemd service using exponential backoff.
systemd's crash-loop protection combines three settings: RestartSec (delay before each restart attempt), StartLimitBurst (max start attempts allowed) and StartLimitIntervalSec (the rolling time window StartLimitBurst is measured against) — if a unit is (re)started more than StartLimitBurst times within StartLimitIntervalSec, systemd marks it failed and stops auto-restarting until the window ages out. This calculator checks whether RestartSec's pacing would let the full burst count actually occur within the configured interval, or whether the interval resets first (making the burst limit effectively unreachable under pure RestartSec-paced restarts alone) — important for correctly tuning crash-loop protection rather than assuming StartLimitBurst always triggers as expected.
Time to exhaust the restart burst
time_to_exhaust_burst = (StartLimitBurst − 1) × RestartSec
The unit enters the 'failed' state (visible via `systemctl status`, showing a start-limit-hit condition) and systemd stops attempting further automatic restarts, even if Restart=always is set — you must manually run `systemctl reset-failed <unit>` (and fix the underlying issue) before it will resume normal restart behavior.
If RestartSec is large enough that the time to reach StartLimitBurst restarts exceeds StartLimitIntervalSec, the interval window rolls forward and resets the count before the burst limit is ever reached — meaning the service can restart-loop indefinitely at that slower pace without ever tripping the 'failed' safeguard, which may or may not be the intended behavior.
A common pattern is a short RestartSec (a few seconds, for fast recovery from transient failures) paired with a StartLimitBurst/StartLimitIntervalSec combination sized so genuine crash loops trip the limit within a reasonable time (e.g. burst=5 within intervalSec=60), giving quick recovery from blips while still catching persistent crash loops.