journalctl for beginners: find Linux errors in system logs

A service fails to start, sound drops out or something stops working after boot. The system journal may already contain a useful message. journalctl helps you select the relevant period and service instead of searching an enormous output for red lines.

This guide assumes Linux with systemd and systemd-journald, as in Cthulhu's NixOS setup. Other init systems may use different tools. The diagnostic queries below are read-only. Only the explicitly labelled exercise message adds a harmless journal entry of your own.

What does the journal contain?

The journal collects structured messages from sources including services and the kernel. Entries include time, source and priority alongside their text. System services such as NetworkManager and user services such as PipeWire belong to different contexts.

Logs are observations rather than a finished diagnosis. A warning can describe expected behaviour, and the actual cause may appear before the visible failure. Start with a concrete question: what stopped working, when did it happen and which service was involved?

Read a small initial excerpt:

journalctl --boot --lines=30 --no-pager

--boot selects the current boot, --lines selects recent entries and --no-pager prints directly. Without the final option, a pager often opens; press q to exit it.

Select the correct boot

A problem after restarting may require the previous boot's messages. List recorded boots:

journalctl --list-boots

If the previous boot is present, query it:

journalctl --boot=-1 --lines=50 --no-pager

0 is the current boot and -1 is the previous recorded one. Retention settings, storage type and permissions may make older boots unavailable. Their absence does not prove that no earlier problem occurred.

Full system-journal access depends on your distribution and group membership. Begin without sudo; repeat a specific query with sudo if it legitimately needs additional access. This does not turn a user service into a system service.

Read one service rather than everything

For a networking problem with NetworkManager, which my NixOS file enables:

journalctl --boot --unit=NetworkManager.service --lines=60 --no-pager

The unit name must actually apply to your computer. Another network-management tool has different service messages. Inspect the associated status separately:

systemctl status NetworkManager.service

A PipeWire user service needs a different context:

journalctl --user --boot --unit=pipewire.service --lines=40 --no-pager

This query needs available user journals. If nothing appears, check service management and journal retention. A manually launched program may write only to its original terminal; not every problem appears under the expected unit.

Combine time and priority filters

A narrow period makes the output easier to follow. Read the last ten minutes of the current boot:

journalctl --boot --since="10 minutes ago" --no-pager

Select warnings and more severe messages:

journalctl --boot --priority=warning --lines=50 --no-pager

A single warning threshold also includes higher-severity entries such as errors. Filters combine, so an overly narrow selection can hide the informative message explaining the problem. After finding a relevant entry, read that service in the same period without the priority filter.

Record the approximate start time and timezone of an incident. Absolute timestamps make repeated comparisons more useful than asking for “ten minutes ago” again an hour later. The displayed local time should match your observation.

Find a message you wrote yourself

This exercise writes one journal entry. It changes no service and is not a genuine failure report:

systemd-cat --identifier=BlogTutorial echo "Local journal exercise"

Search for that identifier:

journalctl --identifier=BlogTutorial --since="5 minutes ago" --no-pager

Expect your message with a timestamp and source, subject to journal permissions. The text deliberately contains no personal data. As a second exercise, change the identifier in both commands and compare the selection.

This teaches filtering without deliberately breaking a service. There is no need to delete journal files or change retention settings.

Follow output and use a repeatable diagnostic process

Watch a service during an operation:

journalctl --boot --unit=NetworkManager.service --follow

Stop watching with Ctrl + C. This stops the reader, not NetworkManager. Avoid restarting networking merely for an exercise if your connection depends on it.

A useful process is to describe behaviour, record the time, select a service, read the context, test one justified change and compare the same excerpt again. My SPDIF article applies this approach to an audio problem; the NixOS rollback guide covers system changes.

Share selected excerpts carefully

Copy a targeted excerpt and redact sensitive values. Uploading an entire journal is rarely the first necessary step. Keep the original for your own investigation: a shortened public excerpt may omit a line that becomes relevant later.

References

• Debian's journalctl manual.
• systemd-cat: the exercise message.
• systemd-journald: storage and access.
• Cthulhu's checked NixOS configuration: the NetworkManager and PipeWire project context.

Sources checked on 8 October 2026. These are exercises; no invented Cthulhu incident logs are presented as real measurements.