systemctl restart and crossing your fingers is not debugging. When a service won't stay up, systemd has already recorded exactly why — you just need to ask it the right questions, in order.
1. Start with status
systemctl status nginx is the one-screen summary: is it active, failed, or stuck activating? It shows the main PID, the exit code, and the last few log lines — often enough to see the cause without going further.
2. Read the journal for the unit
journalctl -u nginx -e # jump to the newest logs journalctl -u nginx --since "5 min ago" journalctl -u nginx -b # just this boot
This is where the real error lives — a config syntax error, a missing file, a port already in use. See reading journalctl for the flags that matter.
3. Decode the exit
In the status output, Result: exit-code with a non-zero status means the program itself refused to run (bad config, permissions). signal=SIGKILL often means it was OOM-killed (see the OOM killer). status=203/EXEC means systemd couldn't even execute the binary — wrong path or not executable.
4. Run the ExecStart by hand
Find the command with systemctl cat nginx (shows the full unit), then run that exact ExecStart line in your shell. Programs are far more talkative on a terminal than through the journal, and you'll usually see the failure immediately.
5. Reload after editing a unit
Changed the unit file itself? systemd won't notice until you systemctl daemon-reload, then systemctl restart. Forgetting the daemon-reload is the classic "I fixed it but nothing changed" trap.
Practise it on failing services
Dead and unresponsive services are bread-and-butter incidents in the simulator. Drill the status → journal → fix loop with Linux troubleshooting practice and a full incident response shift.