Linux service failed to start: diagnose and fix it

What this covers

When a systemd service won't start, the error message is usually vague. This guide walks you through diagnosing the real cause from systemd's own state and logs, then fixing the unit configuration and getting the service running and boot-enabled again.

Symptom

Check the service's state with systemctl status

Before changing anything, find out exactly what systemd knows about the service: whether it's loaded, active, enabled, and what error it printed last. The recent log lines at the bottom usually name the failing component (config error, missing file, port in use). You'll know you have the answer when you can state the active state (e.g. 'failed') and a plausible reason.

$ systemctl status nginx

Scan system-wide error logs since boot

If the status output doesn't make the cause obvious, look at error-priority messages from the whole boot. This catches problems the service itself doesn't log, like missing dependencies, permissions, or SELinux/AppArmor denials. Success looks like a short list you can scan for entries mentioning your service or its dependencies.

$ journalctl -p err -b --no-pager

Watch the service's logs live while retrying

For intermittent or crash-looping services, stream the unit's journal in real time, then restart the service in another terminal and watch what happens at the moment of failure. You'll know it's working when you see new timestamped entries appear the moment you retry.

$ journalctl -u nginx.service -f

Inspect the unit file and its overrides

Many startup failures come from a broken unit file or a stale drop-in override: a wrong ExecStart path, a bad Environment line, or a leftover override from an old install. View the full unit plus every override to spot anything suspicious, and use an override edit to correct it rather than editing vendor files. When the offending line is found and corrected (or removed), move on.

$ systemctl cat nginx.service

$ sudo systemctl revert nginx.service && sudo systemctl daemon-reload

Reload systemd so your unit changes take effect

systemd caches unit files; edits on disk are ignored until you reload. Run the reload after any unit-file or drop-in change, otherwise you'll keep testing the old, broken configuration. It's done when systemd accepts the change with no output and no error.

$ sudo systemctl daemon-reload

Restart the service and read the result

With the cause addressed and units reloaded, do a full restart so the process starts fresh with the new configuration. If the service was already half-running, a restart avoids the confused state a plain start can leave. If it fails again, the status output now reflects the new attempt — take that error back to the diagnosis steps.

$ systemctl restart nginx

$ systemctl start nginx

Make sure the service starts at boot

A service that fails on every reboot but runs when started by hand is often simply not enabled. Enable it so it starts at boot and starts immediately in one step — useful once the underlying failure is fixed. Done when enable reports the symlink was created and the service is active.

$ sudo systemctl enable --now nginx

$ sudo systemctl disable --now nginx

Clear the failed state so monitoring stays clean

After a unit has failed and been fixed, it can stay marked 'failed' and keep alarms firing even though the service is healthy now. Clear the failed state, then confirm with systemctl status that the unit shows active (running). Verification is complete when the service is active, enabled, and no failed units remain.

$ sudo systemctl reset-failed

How to confirm it worked

systemctl status shows the unit as 'active (running)' and enabled for boot, with no failed units left in the output.

Undo everything

Every command above can be reverted. Run these in order to undo all of it.

$ sudo systemctl disable --now nginx
systemctl start nginx
sudo systemctl revert nginx.service && sudo systemctl daemon-reload

Review before running — some steps may not be independent.

Sources

• Ubuntu Manpage: systemctl - Control the systemd system and service manager
  manpages.ubuntu.com · technical · 2026-09-17
  Evidence: "status [PATTERN...|URL...] Show terse runtime status information about one or more units ... This function is intended to generate human-readable output ... along with the most recent log data."
• systemctl(1) — Arch Linux manual
  man.archlinux.org · technical · 2026-09-17
  Evidence: "status [PATTERN...|URL...] — Show terse runtime status information about one or more units, followed by most recent log data from the journal."
• journalctl(1) — Query the systemd journal
  Ubuntu manpages · vendor-doc · 2026-09-17
  Evidence: The manual documents '-p' / '--priority=' to filter by message priority (e.g. err) and '-b' / '--boot' to limit output to a specific boot.
• systemd/Journal - ArchWiki
  Arch Linux Wiki · community · 2026-09-17
  Evidence: The ArchWiki journal page shows filtering journalctl output by priority level and by current boot with examples like journalctl -p err -b.
• systemctl(1) - Linux manual page
  man7.org · community · 2026-09-17
  Evidence: Documents 'systemctl daemon-reload': reload the systemd manager configuration, re-running generators and re-writing user session config.

Last verified: 2026-09-21

Related guides