Debug why a systemd service fails to start using systemctl status and journalctl

Documented steps

1. Get the failure summary: `systemctl status myapp.service --no-pager -l`. Read the Active line (e.g. `failed (Result: exit-code)`), the Process lines with exit status, and the last few log lines it embeds.
2. Pull full logs for just that unit: `journalctl -u myapp.service -e --no-pager`. Add `-xe` to append explanatory catalog text to error entries: `journalctl -xeu myapp.service`.
3. Restrict to the current boot to avoid stale noise: `journalctl -u myapp.service -b`.
4. Interpret the Result field: `exit-code` = main process exited non-zero (check `status=N/EXITED` on the Process line); `signal` = killed by a signal (e.g. status=9/KILL often means OOM or TimeoutStartSec); `timeout` = a Timeout*Sec fired; `start-limit-hit` = restarted too fast too often; `oom-kill` = kernel OOM killer.
5. If status shows `217/USER` the User= account does not exist; `203/EXEC` means ExecStart binary not found or not executable (check the absolute path); `226/NAMESPACE` means a sandboxing option (ProtectSystem, ReadWritePaths, RootDirectory...) references a missing path.
6. Check the unit file systemd actually loaded: `systemctl cat myapp.service` (shows the file path plus all drop-ins).
7. After editing the unit, run `systemctl daemon-reload`, then `systemctl restart myapp.service`, then re-check status.
8. If the unit refuses to start with no attempt logged, check for masking or a failed condition: `systemctl is-enabled myapp.service` (output `masked`), and status line `Condition*` (e.g. ConditionPathExists failed shows as inactive/dead with a Condition note, not failed).