Linux · 3 steps

A systemd unit will not start

Read the Result and the exit status, which name the cause precisely — systemd’s own codes distinguish a missing binary from a bad user from a readiness timeout.

Every step

Read the Result and the exit status

systemd records why it gave up in a single field. `Result=` plus the status code separates a crash from a timeout from a unit file it could not even execute, and those have nothing in common.

$ systemctl status <unit> --no-pager -l

$ systemctl show <unit> -p Result -p ExecMainStatus -p ExecMainCode -p NRestarts

$ systemctl is-failed <unit>

Look for: The `Result=` value, and `status=` in the Main process line. systemd’s own codes — 203/EXEC, 200/CHDIR, 217/USER — name the problem outright.

Read what the service itself said

systemd has told you how it died; now the application tells you why. Its output is in the journal even when the service writes no log file of its own.

$ journalctl -u <unit> -n 100 --no-pager

$ journalctl -u <unit> -S -1h -p err --no-pager

$ journalctl -u <unit> -b --no-pager | head -50 # this boot only

$ systemd-analyze verify /etc/systemd/system/<unit>.service

Look for: The last lines before it exited, and anything from `systemd-analyze verify`, which catches unit-file mistakes systemd otherwise tolerates silently.

Find the dependency that failed

A unit that never ran because something it required failed will report a dependency result. The unit named in the error is where the actual fault is, and starting this one again will not help.

$ systemctl list-dependencies <unit> --failed

$ systemctl --failed --no-pager

$ systemctl list-jobs

$ systemd-analyze critical-chain <unit>

Look for: Which required unit is in a failed state. Requires= propagates failure; Wants= does not.