Reading a Failed systemd Service Without Scrolling Forever

Photo: Unsplash.

When a service fails, start with the unit rather than the entire system journal:

systemctl status myapp.service --no-pager --full

This gives the current state, recent log lines, the main PID, and the command systemd attempted to start. --full prevents long lines from being truncated.

Then read only this boot’s messages for the unit:

journalctl -u myapp.service -b --no-pager

For a shorter window:

journalctl -u myapp.service --since "15 minutes ago" --no-pager

If the service restarts repeatedly, reverse the output so the newest event appears first:

journalctl -u myapp.service -b -r --no-pager

Configuration surprises are common. Inspect the unit plus every loaded drop-in:

systemctl cat myapp.service

Ask systemd for selected effective properties instead of guessing what a directive became:

systemctl show myapp.service \
  --property=FragmentPath,DropInPaths,User,Group,ExecStart,EnvironmentFiles

After editing a unit file or drop-in, reload the manager configuration before restarting:

sudo systemctl daemon-reload
sudo systemctl restart myapp.service

Do not repeatedly restart a service before reading the first failure. A restart can replace the most useful context with secondary errors, especially when the original problem involved a missing file, invalid environment variable, permission failure, or occupied port.

A useful order is: status, focused journal, loaded unit, effective properties, then a deliberate change. It produces less output and preserves the evidence that explains the failure.

References

• systemctl manual
• journalctl manual