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

Summary

Start request repeated too quickly (usually shown as <name>.service: Start request repeated too quickly. followed by Failed with result 'start-limit-hit') means systemd has restarted a service too many times in a short window and has given up. It is a rate-limiter tripping, not the root failure — the service is crash-looping, and systemd’s StartLimitBurst/StartLimitIntervalSec guard fired to stop the loop. The real problem is why each start dies.

Common Symptoms

• systemctl status <unit> shows Active: failed (Result: start-limit-hit).
• The journal repeats several fast start/exit cycles, then Start request repeated too quickly.
• systemctl start <unit> immediately fails with no new log lines (the limiter blocks it).
• The service has Restart=always and a non-zero ExecStart exit.
• It comes back only after systemctl reset-failed.

Most Likely Causes of the ‘Start request repeated too quickly’ Error

The Start request repeated too quickly error appears when a unit exceeds StartLimitBurst starts within StartLimitIntervalSec. Because a healthy service never restarts that fast, the trigger is always an underlying crash. Common production causes, most frequent first:

1. The ExecStart command exits non-zero immediately — missing binary, bad config, wrong path, or a failing dependency.
2. A misconfigured Restart=always/Restart=on-failure with a tiny (or default) RestartSec, so systemd hammers the failing start.
3. A missing resource — a port already in use, an unmounted data dir, a database not yet reachable at boot.
4. Permissions/User= problems — the service user cannot read its config or bind its socket.
5. Type=notify/Type=forking mismatch — systemd thinks the start failed because the readiness contract is wrong.

Quick Triage

systemctl status <unit>                    # look for Result: start-limit-hit
systemctl reset-failed <unit>              # clear the limiter so you can retry
journalctl -u <unit> -b --no-pager | tail -40

reset-failed only clears the counter — if the underlying fault remains, the loop and the error will return.

Diagnostic Commands

journalctl -u <unit> -b                    # every start attempt this boot
journalctl -xb                             # full context with systemd hints
systemctl show <unit> -p ExecMainStatus -p Result -p NRestarts

ExecMainStatus is the exit code of the actual process — that number tells you why each start dies. NRestarts confirms how hard it was looping.

# Inspect the effective unit and its restart/limit settings
systemctl cat <unit>
systemctl show <unit> -p Restart -p RestartSec \
  -p StartLimitIntervalSec -p StartLimitBurst
systemd-analyze verify /etc/systemd/system/<unit>.service

# Run the ExecStart by hand as the service user to see the real error
sudo -u <svcuser> /usr/bin/<binary> --config /etc/<app>/config
ss -ltnp | grep :<port>                    # is the port already taken?

Fix / Remediation

1. Fix the real crash first. Read ExecMainStatus and the journal, then run the ExecStart command manually to reproduce and correct the missing binary / bad config / busy port.

2. Clear the start limiter and retry:

   sudo systemctl reset-failed <unit>
   sudo systemctl start <unit>

3. Give restarts a sane backoff so a transient fault does not trip the limiter. Use systemctl edit <unit>:

   [Service]
   Restart=on-failure
   RestartSec=5

4. Tune the start-limit window to your restart budget (this lives in [Unit]):

   [Unit]
   StartLimitIntervalSec=60
   StartLimitBurst=5

   sudo systemctl daemon-reload
   sudo systemctl reset-failed <unit>
   sudo systemctl start <unit>

5. Order the unit after what it needs so it does not race a dependency:

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

Warning: Do not “fix” this by setting StartLimitBurst=0 (unlimited) to silence it — that removes the guard rail and lets a broken service crash-loop forever, burning CPU and flooding the journal. Fix the crash instead.

Validation

systemctl reset-failed <unit>
systemctl restart <unit>
systemctl is-active <unit>                 # active (running)
systemctl show <unit> -p NRestarts         # should stay at 0 under normal load
journalctl -u <unit> -f                    # watch for a clean, stable start

Prevention

• Set an explicit Restart=on-failure with RestartSec= (2-10s) rather than a bare Restart=always with the default 100ms.
• Size StartLimitIntervalSec/StartLimitBurst to your restart budget so real crash-loops are caught but transient blips are tolerated.
• Order services correctly with After=/Requires= (and network-online.target) so they do not fail-fast on unavailable dependencies.
• Match Type= to the process (notify, forking, simple) so systemd reads readiness correctly.
• Run systemd-analyze verify in CI to catch unit mistakes before they ship. See the Linux admins guides.

Related Errors

• Failed to start unit
• Unit .service not found
• Job timed out
• Permission denied
• Dependency failed for /

Final Notes

Start request repeated too quickly is the rate-limiter, not the disease. reset-failed gets you one more attempt, but the fix is finding why each start dies — read ExecMainStatus, run the ExecStart by hand, and correct the crash. Then give the unit a proper RestartSec backoff and a start-limit window sized to reality so the guard protects you without masking a genuine loop.

Want faster Linux incident response? Use DevOps AI Toolkit to turn production errors into clear diagnostics, remediation steps, and reusable runbooks.