systemctl "failed to start": Reading the One Line That Matters

Published October 2, 2026

⏱️ 2 min read

systemctl status myapp shows a red failed and a wall of text. The line you need is usually buried: look for the indented log lines just under Process, or run the single command that shows the actual error:

journalctl -u myapp -n 50 --no-pager

Almost every failed to start falls into one of three patterns.

Pattern 1: The binary cannot run

Log lines like Exec format error (wrong architecture — an ARM build on x86 or vice versa), No such file or directory (the ExecStart path is wrong, or the script's interpreter line points to a missing binary — also check for Windows line endings in the script), or Permission denied (missing +x, or a path the service user cannot read). Each is a five-second fix once you see it named.

Pattern 2: The service user cannot do what it does

If the app needs a privileged port, /run directory, or device access, running it as a locked-down User= will fail with EPERM errors. Fix the unit, not the security: RuntimeDirectory=myapp creates /run/myapp with the right owner; AmbientCapabilities=CAP_NET_BIND_SERVICE lets non-root bind low ports. Never remove User= to make a service start.

Pattern 3: The startup ordering is wrong

dependency failed or an app crash about missing infrastructure means the unit started before its requirements. Add real dependencies:

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

Then systemctl daemon-reload and start again. A service that fails only sometimes at boot is almost always this pattern — the race resolves differently on fast and slow boots.

Restart behavior worth setting by default

[Service]
Restart=on-failure
RestartSec=5
StartLimitIntervalSec=300
StartLimitBurst=5

This gives crashy-but-recoverable services one honest retry loop without letting a broken unit spin forever.

The discipline that saves the most time: read the journal line first, guess second. journalctl -u <unit> -n 50 answers 90% of failed units before you touch the unit file. If your servers keep accumulating services, a small dedicated VM per role beats one crowded box — see our cloud pick for server sprawl (partner link).