Dennis HilkLinux Fix LabDE

Services & systemd

Crash loops reach the systemd start limit

Repeated restarts eventually stop with start-limit-hit. Find the earliest application failure before changing backoff or resetting the start counter.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • The restart counter rises quickly before the unit fails.
  • A further start is refused with start-limit-hit.

Relevant environment

systemd services with Restart and StartLimitIntervalSec/StartLimitBurst policies.

Recognizable messages (synthetic examples)
systemd[1]: example.service: Start request repeated too quickly.

Find the first failed attempt; the limit is not its cause.

systemd[1]: example.service: Failed with result 'start-limit-hit'.

A configured policy denied a further start.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

  • A configuration fault or unavailable resource can make every attempt exit immediately.
  • A short RestartSec may turn a transient failure into a burst that exhausts the allowed starts.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Replace example.service; reading the counters does not reset them.

systemctl show example.service -p Result -p NRestarts -p Restart -p RestartUSec -p StartLimitIntervalUSec -p StartLimitBurst

Interpret the result: Result identifies the gate, not the original crash. Check whether the restart delay permits recovery of the failing prerequisite.

Check 2

Read the service journal; access may require an authorized administrator or journal group.

journalctl -b -u example.service -o short-monotonic --no-pager -n 200

Interpret the result: Trace back to the first error before repeated restarts. The final start-limit message usually describes a consequence.

Evidence-guided next steps

Repair the first failure, then retry

If the first exit names a configuration or resource fault, correct it first. Then reset only this unit's failed state and start it once with administrator privileges to inspect the result.

Precautions: reset-failed clears relevant rate-limit counters. Repeated resets can hide an unresolved crash loop; retain the journal.

Recovery / rollback: Restore any configuration change that regresses behavior. A reset counter cannot be recreated; compare saved logs.

Did this solution help you?

Share this solution#

Add a deliberate restart delay

If retrying is suitable for the documented failure mode, increase this service's RestartSec and retain a finite start limit. Classify expected clean exits with the application's documented exit-status policy.

Precautions: Backoff increases outage duration. Disabling global limits can let a broken service consume CPU and flood logs.

Recovery / rollback: Restore prior RestartSec and exit-status settings, reload the manager and observe one controlled restart.

Did this solution help you?

Share this solution#

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.