systemd: Start request repeated too quickly

Hi, it's BlueByte. A service that used to restart itself stays down, systemctl status shows it failed, and the journal says Start request repeated too quickly. That line is systemd's start rate limit, not the real failure: the service died several times in a row and systemd stopped retrying. We'll walk through what the limit counts, how to find the crash underneath, the fix per cause, and how to keep it from coming back.

What the journal and systemctl print when the limit trips

Here is the journal from my reproduction on systemd 255 (Ubuntu 24.04), with a unit whose program exits 1 and Restart=on-failure:

myapp.service: Scheduled restart job, restart counter is at 5.
myapp.service: Start request repeated too quickly.
myapp.service: Failed with result 'exit-code'.
Failed to start myapp.service - My App.

The wording from systemctl start depends on the result systemd records. When the result is start-limit-hit, you get this, plus a hint to run reset-failed:

Job for myapp.service failed because start of the service was attempted too often.

In my test on 255 the unit kept its first result, exit-code, so systemctl start said the control process exited with error code instead. Current systemd source records start-limit-hit here, so which line you see depends on your version. Search the journal for repeated too quickly rather than trusting one message.

Why systemd stops retrying

Every unit has a start limit: more than StartLimitBurst= starts within StartLimitIntervalSec= and further starts are refused. Both live in the [Unit] section and default to 10 seconds and 5 starts. The systemd.service manual is explicit that Restart= is subject to the same limit, and RestartSec= defaults to 100 ms. So a program that dies on startup burns five attempts in well under a second, and systemd gives up. That is a guard against a busy loop, not a bug.

The causes fall into three groups:

• The program itself fails on every start: bad config, missing file, port in use, wrong permissions.
• The program fails briefly because something it needs isn't ready yet (a database, a mount, the network), and 100 ms spacing never gives it time.
• Something outside restarts it repeatedly. Every start counts, whether it comes from Restart=, from you, or from a deploy script.

First, find the crash under the rate limit

You don't need to memorize these; three commands tell the causes apart:

systemctl show myapp -p Result -p NRestarts -p RestartUSec -p StartLimitIntervalUSec -p StartLimitBurst
journalctl -u myapp -b --no-pager | grep -v 'Scheduled restart' | tail -n 30
systemctl cat myapp

My test printed NRestarts=5, StartLimitIntervalUSec=10s and StartLimitBurst=5. The journal lines above repeated too quickly are the part that matters: the program's own error, or a status=203/EXEC meaning the ExecStart= binary could not run at all. If there is no crash between the starts, look for whoever keeps restarting it.

Fix it by cause

For a program that always fails, fix the error, then clear the counter and start again. reset-failed only flushes the counter; on its own it changes nothing:

sudo systemctl reset-failed myapp
sudo systemctl start myapp
systemctl is-active myapp
# active

For a dependency that isn't ready yet, space the restarts out with a drop-in instead of editing the vendor unit:

sudo systemctl edit myapp

[Service]
Restart=on-failure
RestartSec=5s

The rule of thumb: if RestartSec × StartLimitBurst is longer than StartLimitIntervalSec, restarts alone cannot trip the limit. When I set RestartSec=3s on the test unit, 14 seconds later it showed NRestarts=4 and SubState=auto-restart — still retrying instead of failed. On systemd 254 and later, RestartSteps= with RestartMaxDelaySec= gives a growing back-off instead of a fixed delay.

For an external restarter, fix the script or timer. Raising StartLimitBurst= only hides it.

A worked example: an API that starts before PostgreSQL

An API unit starts at boot, can't reach PostgreSQL, logs connection refused, and exits. Five restarts 100 ms apart finish before the database accepts connections, and the API sits in failed until someone logs in. The fix has two parts — order it after the database, and give it room to retry:

[Unit]
After=postgresql.service
Wants=postgresql.service
 
[Service]
Restart=on-failure
RestartSec=5s

After the next reboot, systemctl show api -p NRestarts -p ActiveState shows one or two restarts and ActiveState=active. Ordering alone isn't enough when the database takes a while to accept connections, which is why the delay stays.

Check it end to end, then keep it from coming back

Run systemctl is-active myapp, then watch journalctl -u myapp -f through one deliberate systemctl restart myapp. To prevent a repeat, set RestartSec= explicitly on anything with Restart=, declare real dependencies with After=/Wants=, and alert on units in failed state (systemctl --failed). Setting StartLimitIntervalSec=0 disables the limit entirely; a broken program then retries forever at RestartSec pace, so only do it with a sane delay.

How it differs from 203/EXEC and a start timeout

status=203/EXEC means systemd could not execute the ExecStart= program — wrong path, missing execute bit. It is often the crash underneath this error. Job for myapp.service failed because a timeout was exceeded means one start took longer than TimeoutStartSec=: that is one slow start, not many fast ones.

Next time a service stays down, walk these checks back in order: read the journal above repeated too quickly, fix that error, then decide whether the restart spacing needs to change.