A Practical Guide To elementary OS System Logs And journalctl

When an application freezes, Wi-Fi drops out, or the desktop becomes sluggish, the visible symptom rarely explains the cause. elementary OS records a detailed trail of system activity in the systemd journal, including service messages, kernel events, hardware notices and application errors. Learning to read that record gives you a much clearer path from “something went wrong” to a useful diagnosis.

The journal is especially valuable when a problem is intermittent. A failed boot, a Bluetooth device that disappears after waking from sleep, or a laptop that behaves differently on NBN-connected networks can leave evidence long after the original event. With a few terminal commands, you can filter that evidence by time, severity, service or boot session rather than scrolling through an overwhelming wall of text.

Understanding The Journal

elementary OS uses systemd for many core operating system tasks, and systemd-journald collects messages from those services. It receives output from the kernel, background daemons, startup jobs and, in many cases, user applications. The resulting journal is a searchable event log rather than a traditional text file with a single location.

You can begin by opening Terminal and running:

journalctl

The output normally opens in a pager, allowing you to move with the arrow keys, Page Up and Page Down, and exit with q. Newest entries appear at the bottom. To see the latest messages first, use:

journalctl -r

Most entries include a timestamp, the machine name, the process or service name, its process ID and the message itself. The timestamps use your local system time, which is important when matching an event to something you observed. If you are checking an issue that occurred during a video call in Sydney or while commuting with a laptop through Melbourne’s CBD, note the approximate time before searching.

Reading everything is rarely helpful. The journal may contain routine notices from NetworkManager, Bluetooth, desktop services and hardware components that are working normally. The useful approach is to narrow the search to a time window, a boot, or the service connected with the fault.

Filtering Useful Evidence

The simplest time-based filter is:

journalctl --since "today"

You can use more precise expressions:

journalctl --since "2025-07-14 09:00" --until "2025-07-14 10:00"

Relative times are convenient when a problem occurred recently:

journalctl --since "15 minutes ago"

For a complete list of available boots, run:

journalctl --list-boots

The current boot is identified with 0; earlier boots use negative numbers. To inspect the previous startup, use:

journalctl -b -1

This is particularly useful after a failed restart. If elementary OS eventually boots after a forced power-off, the previous boot may contain the graphics, storage or service failure that prevented a normal start.

Severity filters reduce the noise. For messages at error level and above, use:

journalctl -p err -b

You can also include warnings:

journalctl -p warning..emerg

The standard priority scale runs from debug and info through notice, warning, err, crit, alert and emerg. An error is evidence, not automatic proof of the root cause. A failed optional service may be harmless, while an apparently minor kernel message can explain a serious hardware issue.

For live monitoring, use:

journalctl -f

This follows new entries as they arrive, much like watching a log stream. Start it, reproduce the problem, then press Ctrl+C. It can help identify which service reacts when a USB device is inserted, a VPN connects, or a network interface loses its address.

Matching Messages To Services

When a graphical application fails, begin with the application name:

journalctl --user --since "30 minutes ago"

The --user option shows messages from your user session rather than requiring the whole system journal. It can reveal failures involving the desktop session, portals, notifications and user-level applications. For system-wide events, leave out --user.

To inspect a named systemd service, use its unit name:

journalctl -u NetworkManager.service -b

Other useful examples include:

journalctl -u bluetooth.service
journalctl -u cups.service
journalctl -u systemd-logind.service

The exact unit may differ, so list failed services first:

systemctl --failed

Then check the service state and recent journal entries together:

systemctl status service-name.service

Replace service-name.service with the unit shown on your system. systemctl status provides a short summary, while journalctl -u is better for reviewing a longer history.

Kernel and hardware messages can be isolated with:

journalctl -k -b

This is useful for graphics drivers, storage devices, suspend and resume, sound hardware and USB errors. A related command is:

dmesg --level=err,warn

However, dmesg may be restricted on some systems and generally shows the kernel ring buffer rather than the complete persistent journal. For a problem that occurred during an earlier boot, journalctl -k -b -1 is usually more useful.

The community resources at elementarynow can add practical context when a journal message relates to a particular elementary OS release, application or desktop component. When asking for help, provide the relevant command output and describe what happened immediately before the error.

Task	Command	What It Shows
View recent entries	journalctl -e	Jumps to the newest journal messages
Watch events live	journalctl -f	Displays new messages as they are written
Review the current boot	journalctl -b	Events from the present startup
Review the previous boot	journalctl -b -1	Events from the startup before the current one
Show errors	journalctl -p err..emerg	Serious messages across the selected range
Inspect one service	journalctl -u NAME.service	Messages associated with a systemd unit
Show kernel events	journalctl -k	Kernel and hardware-related messages
Search text	journalctl -g "pattern"	Entries whose message matches a pattern
Limit by time	journalctl --since today	Messages from the chosen period

Diagnosing Common Desktop Problems

For Wi-Fi trouble, identify the interface and NetworkManager state first:

nmcli device status
journalctl -u NetworkManager --since "10 minutes ago"

Look for messages mentioning authentication, DHCP, DNS, firmware or a device being disconnected. A DHCP timeout suggests the computer did not receive an address from the router; an authentication failure points more towards the wireless password or security settings. If you are troubleshooting a home connection in Adelaide or regional New South Wales, keep in mind that an NBN outage and a local Linux configuration problem can look similar. Check whether another device is online before changing system settings.

For Bluetooth, run:

journalctl -u bluetooth.service --since "today"

Search for the device name, pairing failures, timeouts or firmware notices. Repeated connect and disconnect events may indicate power management, a low battery or interference rather than a defective elementary OS installation. Copying the surrounding entries is more useful than reporting only one line containing the word “error”.

Graphics issues often appear during login, suspend or resume. Use:

journalctl -b -p warning..err
journalctl -k -b | grep -iE "drm|gpu|amdgpu|i915|nouveau|nvidia"

The driver name depends on the graphics hardware. Messages about a GPU reset, display manager failure or a kernel module not loading can point towards a driver or kernel problem. Avoid copying a command from an unrelated forum without checking the hardware first, especially when a laptop uses hybrid graphics.

For a program that closes unexpectedly, search the user journal around the time it failed:

journalctl --user --since "5 minutes ago" -p warning..err

If the application is launched from Terminal, its direct output may be more informative than the journal. A crash entry can mention a segmentation fault, missing library or permission problem. If the application was installed as a Flatpak, its sandbox and portal messages may appear in user-session logs rather than under a conventional system service.

A slow shutdown or boot requires a different method. Find services that failed:

systemctl --failed

Then inspect the current boot from the end:

journalctl -b -e

Search for terms such as timeout, failed, dependency and job. One timeout may be a consequence of an earlier failure, so follow the sequence instead of assuming the last message is responsible. A laptop used between a warm Queensland home and an air-conditioned office can also expose suspend or resume issues that never appear during a simple cold boot.

Managing Storage, Privacy And Persistence

The journal can occupy disk space over time. Check its size with:

journalctl --disk-usage

On many installations, logs are stored under /var/log/journal when persistent storage is enabled. If that directory is absent, logs may exist only in memory and disappear after a reboot. That is a limitation when investigating a crash that forces the machine to restart.

To remove older entries safely, use a retention rule rather than deleting files manually:

sudo journalctl --vacuum-time=14days

You can limit the total journal size instead:

sudo journalctl --vacuum-size=500M

These commands remove old archived entries, not the newest messages needed for an active investigation. Do not routinely clear the complete journal before diagnosing a fault, because the history may contain the only record of an intermittent failure.

Journal entries can include usernames, device names, network information, file paths and application details. Treat copied output as potentially personal. Before posting logs to a forum, review lines containing IP addresses, home-directory paths, email addresses, serial numbers and wireless network names. The command below can save a focused excerpt for inspection:

journalctl -b --since "today" -p warning..err > elementary-log.txt

Open the file in a text editor and remove sensitive lines before sharing it. Avoid uploading the entire journal when a ten-line excerpt around the failure is enough.

Persistent logging can be configured through /etc/systemd/journald.conf, but most users should leave the defaults alone until there is a clear reason to change them. If you do edit the file, make a backup first and restart the logging service carefully:

sudo cp /etc/systemd/journald.conf /etc/systemd/journald.conf.bak
sudo systemctl restart systemd-journald

A changed logging policy will not repair the original fault. It only affects how much evidence remains available for the next occurrence.

Turning Logs Into A Useful Diagnosis

Good troubleshooting combines the journal with a timeline. Write down what happened, when it happened, whether the issue followed sleep or a reboot, and whether another device showed the same network problem. Then collect only the entries relevant to that period. This prevents a common mistake: treating every warning as a cause simply because it appears in red or contains the word “failed”.

A practical sequence is to check the current boot, filter by severity, inspect the likely service, and then compare the previous boot if the machine was restarted:

journalctl -b -p warning..err
journalctl -u NetworkManager --since "today"
journalctl -b -1 -p err

Replace NetworkManager with bluetooth, systemd-logind, a printer service or another component that matches the symptom. If the same message appears repeatedly before each failure, it deserves attention. If it appears once during normal operation and never returns, it may be incidental.

When searching, use terms that describe the mechanism rather than the symptom. timeout, permission denied, failed to start, firmware, no such file, segfault, oom and dependency are often more informative than “slow” or “broken”. The -g option can search journal message text:

journalctl -b -g "timeout|failed|firmware"

Regular expression support can vary with the installed systemd version, so a simple search may be more reliable if that command produces no output.

If the log points to a package or driver, record the elementary OS release, kernel version and hardware model before making changes:

uname -a
hostnamectl

For support discussions, include the exact command used, the relevant time range and a small redacted excerpt. That gives other users enough context to distinguish a general configuration issue from a release-specific bug, a faulty peripheral or an Australian ISP outage.

Start the next investigation by reproducing the problem once, note the exact local time, and run journalctl --since "10 minutes ago" -p warning..err before rebooting.