🚨 systemd Error: 'Start request repeated too quickly' — Cause, Fix, and Troubleshooting Guide

Overview

Start request repeated too quickly is systemd’s way of saying a unit crash-looped: it failed, Restart= brought it back, it failed again, and this happened enough times inside a short window that systemd gave up and stopped trying. The message is not the root cause — it is the symptom of a Restart=always (or on-failure) unit whose ExecStart keeps exiting non-zero almost immediately.

The journal shows the loop and then the surrender:

$ systemctl status myjob.service --no-pager
× myjob.service - Nightly export job
     Loaded: loaded (/etc/systemd/system/myjob.service; enabled)
     Active: failed (Result: exit-code) since Sun 2026-07-12 02:14:07 UTC; 3s ago
    Process: 4821 ExecStart=/opt/jobs/myjob.sh (code=exited, status=203/EXEC)

Jul 12 02:14:06 host systemd[1]: myjob.service: Scheduled restart job, restart counter is at 5.
Jul 12 02:14:07 host systemd[1]: myjob.service: Start request repeated too quickly.
Jul 12 02:14:07 host systemd[1]: myjob.service: Failed with result 'exit-code'.
Jul 12 02:14:07 host systemd[1]: Failed to start Nightly export job.

By default systemd allows StartLimitBurst=5 starts within StartLimitIntervalSec=10s. Cross that and the unit is rate-limited into a failed state and will not restart — even when the underlying problem is later fixed — until you clear the failure with systemctl reset-failed.

Symptoms

• systemctl status shows Active: failed (Result: exit-code) and the log line Start request repeated too quickly.
• Preceding log lines show Scheduled restart job, restart counter is at N climbing 1..5.
• ExecStart exits within a second or two every time (e.g. status=203/EXEC, status=1, status=217/USER).
• The unit stays down even after you fix the cause, until reset-failed is run.
• A timer- or restart-driven service flaps repeatedly at boot or on schedule.

systemctl is-active myjob.service; systemctl is-failed myjob.service

failed
failed

Common Root Causes

1. ExecStart fails instantly

The command cannot even start — wrong path, not executable, or missing interpreter — so it exits immediately and the restart loop burns through the burst limit in seconds.

systemctl show -p ExecStart --value myjob.service

{ path=/opt/jobs/myjob.sh ; argv[]=/opt/jobs/myjob.sh ; ... }

status=203/EXEC means systemd could not execute that path at all.

2. Restart=always on a unit that can never succeed

The unit is genuinely broken, but Restart=always keeps relaunching it, guaranteeing the rate limit is hit. The restart policy turns a single failure into a crash loop.

3. StartLimitIntervalSec / StartLimitBurst too tight for the failure mode

Even a unit that will eventually succeed (waiting on a dependency) can trip the limit if it retries faster than the burst allows.

4. Missing dependency or wrong ordering

The service starts before something it needs — the network, a mount, a database socket — so it fails, restarts, and fails again until the limit trips. A missing After=/Requires= is the usual culprit.

5. Wrong path, permissions, or user

status=203/EXEC (bad path / not executable), status=217/USER (the configured User= does not exist), or status=200/CHDIR (bad WorkingDirectory=) all cause instant failures that loop.

How to Diagnose

Read the status and the exact exit code first — the status= value names the failure class:

systemctl status myjob.service --no-pager -l

    Process: 4821 ExecStart=/opt/jobs/myjob.sh (code=exited, status=203/EXEC)

203/EXEC points straight at the binary: does it exist, is it executable, does it have a valid shebang?

ls -l /opt/jobs/myjob.sh
head -1 /opt/jobs/myjob.sh

-rw-r--r-- 1 root root 412 Jul 12 01:59 /opt/jobs/myjob.sh
#!/usr/bin/env bash

The file is not executable (-rw-r--r--), which fully explains 203/EXEC.

Pull the full loop from the journal to confirm the counter climbing and see any application error before the surrender:

journalctl -u myjob.service -n 40 --no-pager

Jul 12 02:14:04 host systemd[1]: myjob.service: Main process exited, code=exited, status=203/EXEC
Jul 12 02:14:04 host systemd[1]: myjob.service: Failed with result 'exit-code'.
Jul 12 02:14:05 host systemd[1]: myjob.service: Scheduled restart job, restart counter is at 4.
Jul 12 02:14:06 host systemd[1]: myjob.service: Scheduled restart job, restart counter is at 5.
Jul 12 02:14:07 host systemd[1]: myjob.service: Start request repeated too quickly.

Check the effective restart and rate-limit settings, and verify ordering dependencies:

systemctl show myjob.service -p Restart -p RestartUSec -p StartLimitBurst -p StartLimitIntervalUSec
systemd-analyze verify /etc/systemd/system/myjob.service

Restart=always
RestartUSec=100ms
StartLimitBurst=5
StartLimitIntervalUSec=10s

RestartUSec=100ms with Restart=always means a failing unit retries ten times a second — it will hit the burst limit almost instantly.

Fixes

Fix the underlying failure first

The rate limit is a consequence, not the disease. Address whatever status= reported. For 203/EXEC, make the script executable and confirm the interpreter:

sudo chmod +x /opt/jobs/myjob.sh
sudo -u myuser /opt/jobs/myjob.sh; echo "exit=$?"

exit=0

Run the command by hand as the unit’s User= to prove it succeeds before re-enabling it.

Clear the failed state

Once the unit can succeed, systemd still holds it in the rate-limited failed state. Reset the counter, then start:

sudo systemctl reset-failed myjob.service
sudo systemctl start myjob.service
systemctl is-active myjob.service

active

Add proper ordering and dependencies

If the failure is a startup race, order the unit after what it needs so it does not fail-and-loop waiting:

[Unit]
After=network-online.target postgresql.service
Requires=postgresql.service
Wants=network-online.target

Tune the restart backoff and limits

Give failing restarts breathing room so a transient problem does not trip the limit, and slow the retry cadence:

[Service]
Restart=on-failure
RestartSec=10
StartLimitIntervalSec=60
StartLimitBurst=5

sudo systemctl daemon-reload
sudo systemctl reset-failed myjob.service
sudo systemctl start myjob.service

RestartSec=10 spaces out attempts so five retries span 50 seconds instead of half a second, and StartLimitIntervalSec=60 widens the window. Note that StartLimitIntervalSec and StartLimitBurst live in the [Unit] section on older systemd; systemd-analyze verify will flag placement issues.

Do not paper over a permanently broken unit

If the command can never succeed, raising StartLimitBurst just makes it loop longer. Fix or disable the unit rather than letting it flap forever.

What to Watch Out For

• The rate-limit message hides the real error. Always read the status= code and the journal lines above Start request repeated too quickly — that is where the actual failure (203/EXEC, 217/USER, exit 1) lives.
• reset-failed is required after fixing the cause. systemd will not restart a rate-limited unit on its own; a fixed unit stays down until you clear the counter. This trips people up constantly — the fix “did not work” only because the failed state was never reset.
• RestartSec too small guarantees the loop. A default or tiny RestartSec with Restart=always retries so fast it exhausts the burst before the dependency it needs is even ready. Space restarts out.
• Raising StartLimitBurst is not a fix for a broken command. It just converts a fast crash loop into a slow one and floods the journal. Fix ExecStart first.
• StartLimit directives moved sections across systemd versions. On newer systemd they belong in [Unit]; misplaced in [Service] they are silently ignored. Validate with systemd-analyze verify.
• status=217/USER and 200/CHDIR are unit-config errors, not app bugs — the User= does not exist or WorkingDirectory= is wrong. Check the unit before touching the script.

Related Guides

• systemd Timer Failed with Exit Code
• Cron Grandchild Process Failed
• Scheduled Job Orchestration at Scale