Systemd Can Stop Restarting a Service That Fails Too Often

Consider a voice application whose inference service exits while loading a missing model file. Its unit says Restart=on-failure, so systemd tries again. After several quick failures, retries stop. An operator who reads only the restart directive may expect the service to keep trying indefinitely.

Two settings govern different parts of this sequence. Restart= in systemd.service selects which exits and timeouts trigger an automatic restart. RestartSec= sets the delay before each retry. StartLimitIntervalSec= and StartLimitBurst= in systemd.unit count starts within a time window and reject starts beyond the burst. The limit applies to manual starts as well as automatic ones.

For example, this illustrative unit allows a small burst while leaving time to inspect a broken service:

[Unit]
StartLimitIntervalSec=60s
StartLimitBurst=3

[Service]
ExecStart=/opt/voice/bin/inference-server
Restart=on-failure
RestartSec=5s

If each attempt fails promptly, the first start and two retries can consume the three allowed starts. The next start is refused until the rate window allows another one. The exact sequence depends on when each attempt occurs; a slower failure or longer restart delay changes the count within the window. Systemd’s unit documentation also notes that once the interval has passed, a later manual, timer, or socket start can run and restart logic can operate again. It does not promise an automatic retry at the instant the window expires.

Recover the service, then its retry path

Begin with systemctl status inference.service and the service journal to find the actual failure. In this example, restore the model file or correct its path and permissions, then verify that the application can initialize. Changing the burst value to suppress the symptom leaves the same failure in place and can create a faster failure loop.

systemctl reset-failed inference.service clears the failed state and the service’s start-rate counter. The unit manual explicitly describes the counter reset as useful when a manual start is blocked. It does not repair the missing file. After fixing the cause, reset the counter if it still blocks recovery, start the service, and verify that it stays active and serves a real inference request. Keep the limit as a guard against repeated failed starts, not as a substitute for application health.