systemd Start Request Repeated Too Quickly: Find the Real Failure

When systemctl status reports Start request repeated too quickly, systemd has stopped accepting new start attempts for that unit because its configured rate limit was reached. It does not tell you why the service failed in the first place. The useful evidence is usually earlier: the first failed execution, timeout, missing file, rejected permission or application error.

The safe order is inspect the original failure → repair the cause → clear the rate-limit counter if necessary → start once and verify. Increasing the limit or repeatedly running reset-failed can hide the initial fault without correcting it. This distinction follows from systemd's start-limit rules and restart policy rules.

This guide is for Linux developers and administrators troubleshooting an ordinary system service under systemd. Commands use myapp.service as a placeholder: substitute the actual service you are authorised to administer. Read-only diagnostics come first; commands that affect service state appear later. The procedures are documentation-based, not claimed to have been run on a production server. Exact defaults and available properties depend on the installed systemd version and distribution.

The restart limit is a symptom, not a root cause

The common pattern is that a service starts, its main process exits unsuccessfully, systemd schedules a retry under its Restart= policy, and the same fault happens again. When too many starts occur during the configured interval, further starts are refused. The limit can also count manual attempts, so the mere presence of this message does not prove automatic restarts are enabled. The systemd.unit documentation defines StartLimitIntervalSec= and StartLimitBurst= and describes their interaction with Restart=.

Two separate sets of settings matter. Restart= and RestartSec= decide whether and how quickly a service is tried again. StartLimitIntervalSec= and StartLimitBurst= decide how many starts are permitted within a time window. The latter settings live in the [Unit] section; restart policy settings live in [Service]. A vendor unit, a local override or manager defaults may supply the effective values. Never guess what your machine uses.

1. Collect evidence before you reset anything

Identify the exact unit name first. On a system service, run these commands without changing configuration or restarting the process:

sudo systemctl status --no-pager --full myapp.service
sudo journalctl -u myapp.service -b -n 120 --no-pager

systemctl status provides a concise state summary. journalctl -u retrieves entries associated with the unit, including relevant manager messages; -b restricts the view to the current boot and -n 120 chooses the latest 120 entries. The systemctl manual and journalctl manual document these options. If the failure happened on an earlier boot, omit -b and inspect the appropriate retained time range.

Scroll back from the final start-limit message until you find the earliest useful failure. In a restart loop, later journal entries may repeat an error or simply report that the next start was rejected. The first failed execution may be the only place a missing path, application stack trace or permission error is obvious. Collect the relevant lines before clearing the failed state.

If no application error appears, the service might write to its own log file, terminate before logging starts or not expose all messages through the journal. Consult that application's documented logging behavior. Treat command output as potentially sensitive; redact secrets, environment values, hostnames and personal information before posting it publicly.

2. Interpret the result without jumping to conclusions

A final start-limit-hit result does not replace the preceding error. Use the status and journal together, not one field in isolation:

These are investigation routes, not a universal code-to-cause mapping. The systemd.service reference explains how exit status, signals and timeouts interact with service state and restart decisions. The systemd.exec reference describes the execution environment, which may differ substantially from the environment in your interactive shell.

This original schematic shows the reasoning order. It is not a screenshot, a timing chart or a claim that every failed service has automatic retries.

Original Jitsumi diagram: investigate the first failure before clearing counters.

3. Read the effective service definition and overrides

Systemd services can be defined by a vendor file plus one or more drop-ins. Inspecting a single file under /usr/lib/systemd/system/ or /lib/systemd/system/ can miss a local override. Ask systemd for the backing files and normalized properties:

sudo systemctl cat myapp.service
sudo systemctl show myapp.service \
  -p ActiveState -p SubState -p Result \
  -p ExecMainCode -p ExecMainStatus -p NRestarts \
  -p Restart -p RestartUSec \
  -p StartLimitIntervalUSec -p StartLimitBurst

systemctl cat shows unit source files and drop-ins; show provides machine-readable properties and runtime state. Time-related property names may end in USec, even where the original unit directive uses Sec. Some properties differ by systemd release or unit type; if your system omits one, consult its installed man systemctl and unit manuals rather than inventing a value. The systemctl reference distinguishes the displayed sources from the manager's loaded configuration.

Look at ExecStart=, ExecStartPre=, User=, WorkingDirectory=, EnvironmentFile=, Type= and any restrictions specific to the service. Running the same executable directly in your shell does not reproduce a system service's account, environment or filesystem restrictions. The systemd.exec manual explains these differences.

Worked example: the configured working directory disappeared

Suppose a deployment moved an application from /srv/myapp/current to a new release folder but left WorkingDirectory=/srv/myapp/current in its service definition. The service may fail during execution setup, before its usual application logger is available. A restart limit can then appear after repeated failed attempts. Increasing the restart count would merely repeat a missing-directory error.

The relevant checks are narrow and read-only:

sudo systemctl cat myapp.service
ls -ld /srv/myapp/current
sudo journalctl -u myapp.service -b -n 120 --no-pager

ls -ld establishes whether that precise directory exists, not whether every parent is traversable by the configured service account. If it exists, examine ownership, parent-directory permissions and unit restrictions before drawing a conclusion. If a deployment deliberately moved it, repair the deployment path or the appropriate override through the application's supported procedure. Do not make directories world-writable to silence an unverified permission error.

This example illustrates a plausible diagnosis; it is not a reproduced incident. It demonstrates why the first execution error and the actual unit configuration matter more than the repeated start-limit message. WorkingDirectory= behavior is defined in the systemd execution environment specification.

4. Fix the fault before tuning restart behavior

A service might be unable to read a configuration file, execute its binary, reach a dependency, allocate memory or write logs. Some faults are transient; others will recur until somebody changes a path, credential, deployment or resource condition. Let the first failure choose the investigation. If the journal says No space left on device, inspect the affected filesystem first. Jitsumi's separate guide to Linux disk space held by deleted-but-open files covers one less obvious reason disk space may not return after deletion.

Only after understanding the fault should you reconsider the retry policy. For an application you maintain, prefer an override rather than editing a vendor-owned unit file:

sudo systemctl edit myapp.service

For example, a long-running service that benefits from a controlled retry after a transient failure might use the following drop-in. The numbers are illustrative, not universal best practices:

[Unit]
StartLimitIntervalSec=60s
StartLimitBurst=5

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

Here, Restart=on-failure makes qualifying failures eligible for automatic retry and RestartSec=10s delays those retries. The [Unit] directives still enforce a cap on start attempts in a 60-second window. The combination is not a guarantee that the service will recover, and the cap can still be reached if the fault persists. The service manual and unit manual explain the interaction. Do not disable start-rate limiting to conceal a permanent error.

On successful exit, systemctl edit normally saves the drop-in and reloads the manager's unit definitions. If you manually edit a unit file instead, run sudo systemctl daemon-reload. That reload changes systemd's understanding of units; it does not tell the application to re-read its internal configuration, and it does not automatically restart the service. See systemctl edit and daemon-reload.

Where you have the actual unit-file path, a useful static check is:

sudo systemd-analyze verify /path/to/myapp.service

Replace the example path with the real unit file identified by systemctl cat; a packaged or generated unit may not live under /etc/systemd/system/. systemd-analyze verify reports unit-file problems but cannot prove that the daemon will start successfully or accept client requests. Its documented scope is narrower than application testing: see systemd-analyze verify.

5. Reset the failure counter only after repairing the cause

After correcting the error, inspect the state and journal again. If the rate limit continues blocking a start, clear the failed state for this unit only, then attempt a controlled start and check new evidence:

sudo systemctl reset-failed myapp.service
sudo systemctl start myapp.service
sudo systemctl status --no-pager --full myapp.service
sudo journalctl -u myapp.service -b -n 60 --no-pager

reset-failed clears the stored failed state along with the unit's start-rate counter and service restart counter. It does not repair files, credentials, commands or dependencies. Calling it with no unit argument would reset failed-state information more broadly. The systemctl reset-failed documentation describes the operation precisely.

A successful systemctl start is only an initial checkpoint. Verify the service's intended behavior: a documented health endpoint, client connection, expected output file, successful job completion or other application-specific evidence. Then allow enough ordinary workload to detect an immediate recurrence. A one-shot task that exits normally can be inactive by design; do not insist that every unit stay active (running).

If it fails again, preserve the new journal entries and compare the first error with the previous one. You may have fixed one fault and exposed another. Increasing StartLimitBurst repeatedly is not a substitute for diagnosis. Coordinate changes on shared or critical machines rather than looping restarts that affect users.

What if this sequence does not fit?

A user service is controlled using systemctl --user and inspected using journalctl --user -u; the commands above target the system service manager. A socket-activated service has its own trigger path, and a container without systemd as its service manager requires different diagnostics. Some units are deliberately short-lived. Check the unit type and manager before applying the procedure.

The rate-limit window can eventually expire, allowing a later attempt or trigger to start the unit. That does not prove the application problem was resolved. Systemd distinguishes a start counter from the original execution failure in its unit rate-limiting specification.

The reliable way out of a restart loop

Treat Start request repeated too quickly as the end of a failure sequence, not the fault itself. Find the earliest useful journal entry, inspect the real unit and overrides, repair the observed cause, then reset and validate the service deliberately. That preserves evidence and keeps a noisy crash loop from masquerading as recovery.