linux troubleshooting guide

systemd Service Failed: What to Check First

Use systemd's failed-unit state, then inspect one unit with status and journal output before deciding whether restart, config repair, or dependency work is needed.

Problem

After a reboot or deploy, something is unhealthy. You need to find failed units and identify the first useful error without blindly restarting services.

First rule

Read the failed state and logs before clearing or restarting the unit.

Audience

Linux learners, junior administrators, service owners, and certification students

Cert context

Unofficial practice for service management, logs, boot troubleshooting, and operational triage.

quick start

Safe first commands

systemctl --failed --no-pager
systemctl status nginx --no-pager
journalctl -u nginx -b --no-pager
journalctl -u nginx --since '30 minutes ago' --no-pager

List failed units

`systemctl --failed` gives the triage list that systemd already knows about. Start there after boot, deploy, package updates, or unexplained host behavior.

systemctl --failed --no-pager

Inspect status without paging

Status output often includes the active state, main PID, exit code, and the last few journal lines. It is a summary, not a full investigation.

systemctl status nginx --no-pager

Read the unit journal for this boot

The journal usually contains the useful detail: config parse failures, missing files, permission denials, dependency errors, or repeated restart attempts.

journalctl -u nginx -b --no-pager
journalctl -u nginx --since '30 minutes ago' --no-pager

Reset failed only after capturing evidence

`systemctl reset-failed` clears state; it does not fix the cause. Use it after you have saved or understood the failure details.

systemctl reset-failed nginx

triage logic

How to read the result

status shows an exit code or signal

The process started and then exited in a way systemd recorded.

Next: Read journal lines before and after the exit for the application-specific cause.

journal shows permission denied

The service user may not be able to read files, write directories, or bind privileged ports.

Next: Inspect permissions and service configuration before chmod.

the unit restarts repeatedly

Restart policy is hiding the first failure behind repeated attempts.

Next: Find the earliest failure line in the boot window.

safety notes

Slow down here

Do not clear failed state before recording useful output.
Avoid repeated restarts when config or permissions are still broken.
Restarting production services may affect users; treat it as a change.

related lessons