journalctl Tutorial: Read systemd Logs and Debug Boot Errors

On a systemd-based Linux system, journalctl queries records collected by the systemd journal. Running journalctl with no additional match displays the journal entries the current user is allowed to see. That can be useful for orientation, but a complete journal is usually too broad for efficient troubleshooting.

A safer diagnostic workflow is to identify when the problem happened and which boot or service is involved, then add filters one at a time. A red error line is evidence from one component at one point in time; it is not automatically the root cause. Earlier warnings, dependency failures, kernel messages, or a later recovery can change the interpretation.

The -b or --boot option restricts output to a specific boot. With no boot ID or offset, journalctl -b selects the current boot. An offset of -1 selects the boot before the latest retained boot, while --list-boots shows the boot numbers, IDs, and time ranges that are actually present in the accessible journal.

For a machine that failed during startup and then worked after a reboot, the previous boot is often more useful than the current one. Start with journalctl --list-boots, confirm that the failed boot exists, then inspect it with journalctl -b -1 or the corresponding boot ID. Do not assume that -1 will always be available: retained history depends on journal storage, cleanup policy, disk state, and permissions.

The -u or --unit option restricts results to a named systemd unit, such as journalctl -u NetworkManager.service or journalctl -u ssh.service. Unit filtering is useful after systemctl identifies a failed service, because it removes unrelated application and kernel chatter while preserving the service journal context.

Filters can be combined. For example, journalctl -b -1 -u example.service asks for that unit during the previous retained boot. systemd documents additional constraints such as --boot and --unit as cumulative matches, so combining them narrows the same query rather than creating separate searches.

journalctl can filter by syslog-style priority with -p or --priority. This is useful when a large boot journal needs an initial pass for higher-severity records. It should not be treated as a rule that only error-priority messages matter: the component that ultimately fails may have been affected by an earlier warning, timeout, dependency, device event, or otherwise ordinary-looking message.

Use a priority filter to reduce noise, then widen the context around promising timestamps. Avoid deleting context simply because a line is not marked as an error. Severity is metadata supplied by the logging path; it does not prove causality.

The --since and --until options constrain journal entries by time. They are useful when you know approximately when a freeze, disconnect, failed login, service restart, or other event occurred. Instead of scanning an entire day, query a small interval around the observed failure and then expand the window if necessary.

systemd accepts documented timestamp forms rather than requiring one universal hard-coded format. Keep the time boundary tied to the system whose journal you are reading, and remember that an event timestamp establishes ordering, not causation. Correlating several components around the same time is often more informative than isolating the final error alone.

The -k or --dmesg option restricts the journal to kernel messages. Pairing it with a boot filter, such as journalctl -k -b, is useful for driver initialization, storage, networking, USB, graphics, firmware, and other failures where the kernel side of the event matters.

Kernel messages are still only one layer of the diagnosis. A desktop application can fail because of a userspace service even when the kernel journal is quiet, and a kernel warning does not automatically mean the warned-about component caused the symptom. Compare kernel output with the relevant service and application records before drawing a conclusion.

The -f or --follow option prints recent entries and continues displaying new records as they are appended. Combining it with a unit filter, for example journalctl -u example.service -f, is a practical way to watch a service while reproducing a harmless failure or changing a setting.

Follow mode is observation, not a reason to repeatedly reproduce a destructive or hardware-risking failure. If the problem involves data loss, overheating, unstable power, storage corruption, or another unsafe condition, preserve the existing logs and diagnose without intentionally triggering it again.

systemd-journald can keep journal data persistently under /var/log/journal or use volatile storage under /run/log/journal. Current systemd documentation describes Storage=auto as using persistent storage when /var/log/journal exists and otherwise using volatile storage; Storage=persistent, volatile, and none provide explicit alternatives. Distribution configuration can change the effective behavior.

Volatile journal data is lost at reboot, so a missing previous boot does not prove that nothing was logged. First use journalctl --list-boots to see what history is available. If persistent history is required, consult the systemd journald.conf documentation and your distribution guidance before changing storage policy; do not assume every distribution ships the same configuration or retention limits.

journalctl only shows records the invoking user is permitted to read. systemd documentation notes that ordinary users have access to their private user journals, while access to the complete system journal is normally limited to root and users granted the relevant system-journal privileges; exact administrative group conventions can vary by distribution.

If a command returns less information than expected, distinguish an empty journal from an access limitation before concluding that the event was never recorded. Using elevated privileges may expose additional system records, but do so only when appropriate for the machine and account rather than making sudo a reflexive part of every journalctl command.

For a boot-related problem, first run journalctl --list-boots and identify the boot where the symptom occurred. Inspect that boot broadly, then narrow to a suspected service with -u, to kernel messages with -k, or to a known time interval with --since and --until. Use a priority filter as an additional triage view rather than discarding the surrounding records.

Once you find a relevant message, read entries before and after it and identify which component emitted it. Check the corresponding systemd unit status, driver, device, or application documentation before changing configuration. The goal is to turn a large event stream into a reproducible evidence chain, not to search for the first line containing the word error and treat it as a diagnosis.