On systemd-based Linux distributions, a service that “will not start” can fail for many reasons: an invalid command, missing file, permission problem, dependency failure, timeout, or application crash. A repeatable workflow is faster than repeatedly restarting the unit.

Start with unit state

systemctl status example.service

Look at Loaded, Active, the main process exit status, and the most recent log lines. A unit can be loaded correctly while its process exits immediately.

For machine-readable state, query individual properties:

systemctl show example.service -p ActiveState -p SubState -p Result -p ExecMainStatus

Read logs for the unit

journalctl -u example.service --since "30 minutes ago"

Use -b to restrict output to the current boot and -f to follow new messages while reproducing a failure:

journalctl -b -u example.service -f

Do not paste secrets into diagnostic commands or publish logs without reviewing them; environment values, request data, and credentials can appear in application output.

Inspect the effective unit definition

A service may have vendor defaults plus local drop-ins. Show the effective configuration and source files with:

systemctl cat example.service

After editing a unit or drop-in, reload systemd’s configuration before restarting:

sudo systemctl daemon-reload
sudo systemctl restart example.service

daemon-reload does not restart services by itself.

Check dependencies and ordering

systemctl list-dependencies example.service

A failed requirement can prevent startup. Remember that ordering and requirement relationships are different concepts: After= controls ordering, while directives such as Requires= express dependency behavior.

Verify the process outside systemd carefully

If the unit’s ExecStart command is safe to run manually, execute the application with equivalent arguments under a non-privileged test context. This can reveal syntax or file errors more directly.

Do not casually copy the service’s full environment into a shell. Production units may reference sensitive environment files or credentials.

Common pitfalls

Restarting before reading evidence

A restart can replace useful state and make intermittent failures harder to understand. Capture status and logs first.

Editing vendor unit files directly

Package upgrades can overwrite files under vendor-managed locations. Prefer systemctl edit example.service for local overrides when appropriate.

Assuming “enabled” means “running”

Enablement controls whether a unit is wired into startup targets. Runtime state is separate. Check both when diagnosing boot behavior.

Ignoring exit codes

ExecMainStatus and application logs often point directly to configuration, permission, or resource failures.

Build a small diagnostic sequence

A reliable order is: inspect status, read current-boot logs, inspect the effective unit, check dependencies, verify referenced paths and permissions, then restart after correcting the cause. This keeps troubleshooting evidence-driven and avoids turning service management into trial and error.

Linux Systemd Journalctl Troubleshooting