A Gentle First Pass With journalctl

Photo: Unsplash.

journalctl becomes much easier when the first query is narrow. For a failed service, ask for the current boot, the exact unit, recent context, and readable timestamps:

sudo journalctl -b -u example.service -n 100 -o short-iso

This avoids mixing last week’s failure with today’s restart. Add --no-pager when sending the output into another command or a ticket:

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

To follow new entries after reading the recent context:

sudo journalctl -b -u example.service -n 50 -f

Press Ctrl-C to stop following. If the service name is uncertain, list units or inspect the service with systemctl status before guessing variations.

Use time as a boundary

The journal accepts human-friendly times:

sudo journalctl -u example.service \
  --since "2024-01-28 14:00" \
  --until "2024-01-28 14:20" \
  -o short-iso

For boot problems, list recorded boots and select one explicitly:

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

-b -1 means the previous boot. This distinction matters when a reboot temporarily clears the visible symptom.

Priority filtering can reduce noise, but use it carefully:

sudo journalctl -b -p warning

That query can hide informative messages immediately before an error. I prefer to find the failure in a narrow unit query, note its timestamp, then widen the time window across the system to see related network, disk, or dependency events.

Logs are most useful when treated as a timeline rather than a bag of error strings. Begin with a known unit and boot, locate the moment behavior changed, and widen only as the evidence asks for it.

Reference

• journalctl manual