How to Troubleshoot Failed Linux Services with journalctl

When a Linux service stops working, start by collecting the error and its timestamp. On a system using systemd, journalctl can narrow the logs to the relevant boot or service. The commands below inspect existing information; they do not restart services or delete logs.

1. Find the failed service

systemctl --failed --type=service --no-pager

This lists service units currently marked failed. Copy the exact unit name from the output. In the examples below, example.service is a placeholder you must replace.

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

The status view shows the current state and recent journal messages. The systemctl manual explains that failures can result from a crash, an error exit or a timeout. An inactive service is not automatically a failed one. If the failed list is empty, continue with the service you know is affected.

2. Read the relevant journal entries

sudo journalctl -b -u example.service -n 50 --no-pager

Here, -b selects this boot, -u selects the unit and -n 50 limits the result to the latest 50 matching entries. Administrator access may be needed for the full system journal.

sudo journalctl -b -p err --no-pager

This second command shows errors and higher-severity messages across the current boot. The journalctl manual defines these filters. Keep the first query without a priority filter when you need the warnings or ordinary messages leading up to a failure.

3. Check the previous boot

sudo journalctl --list-boots
sudo journalctl -b -1 -u example.service --no-pager

The first command lists retained boots; the second selects the previous boot for your service. If that boot is unavailable, the command cannot recover records that were never retained.

Why older logs may be missing

The journald configuration manual distinguishes volatile storage under /run/log/journal from persistent storage under /var/log/journal. With the default namespace’s Storage=auto behavior, the presence of the persistent directory determines which mode is used. Distribution settings and retention limits can also affect what remains available.

Changing retention today will not recreate yesterday’s missing evidence. For a useful troubleshooting report, record the affected service, the time the problem occurred and the first relevant error. Read the surrounding messages before selecting a fix: an error elsewhere on the machine may be unrelated to the symptom you are investigating.