Reading Logs with journalctl

One log for everything

Windows has the Event Viewer; Linux used to have a folder of separate text files. On systemd systems there’s the journal: the kernel, every service, and the output of every program systemd starts all go to one service, systemd-journald, which stores them with the time, the unit, the priority, and the boot they came from ^{1 2}.

By default it’s kept on disk under /var/log/journal, so logs survive reboots ³. That matters most when something went wrong and you had to restart.

journalctl reads it. With no options it shows everything, oldest first, in a pager ¹. The pager is less: Space for the next page, G for the end, / to search, q to quit.

Who can read it

Your own user services’ logs are always readable by you. The system journal is readable by root and by members of the groups adm, systemd-journal, and wheel ¹. Check with groups: if adm is listed, journalctl works without sudo; otherwise use sudo journalctl.

This boot and the last

me@garden-laptop:~$ journalctl -b
me@garden-laptop:~$ journalctl -b -1
me@garden-laptop:~$ journalctl --list-boots

-b limits it to the current boot; -b -1 to the one before, -b -2 the one before that ¹. --list-boots shows a numbered table of the boots in the journal with their first and last times ¹. After a crash or freeze, the previous boot is where the clues are.

One service

me@garden-laptop:~$ journalctl -u ssh
me@garden-laptop:~$ journalctl -b -u cups

-u shows one unit’s messages ¹. The few lines at the bottom of systemctl status are the same thing, cut short; journalctl -u gives the whole story.

Only the problems

Every message has a priority, the standard syslog levels from 0 (emerg) to 7 (debug): emerg, alert, crit, err, warning, notice, info, debug ¹. -p shows that level and everything more serious:

me@garden-laptop:~$ journalctl -b -p err
me@garden-laptop:~$ journalctl -b -1 -p warning

-p err is levels 0 to 3 ¹. Some errors on every boot are normal, from hardware or features you don’t use. What you’re looking for is what’s new or what lines up with the trouble.

By time

me@garden-laptop:~$ journalctl --since today
me@garden-laptop:~$ journalctl --since "1 hour ago"
me@garden-laptop:~$ journalctl --since "2026-10-05 14:00" --until "2026-10-05 14:30"

--since and --until take a date and time like 2026-10-05 14:00, the words yesterday, today, and now, or a relative time like "1 hour ago" ¹.

As it happens

me@garden-laptop:~$ journalctl -f
me@garden-laptop:~$ journalctl -f -u ssh

-f follows the journal, printing new lines as they arrive until Ctrl-C ¹. Start it in one terminal, then reproduce the problem in another, plugging in the device or trying the connection, and watch what gets logged. The manual’s own example is following a web server, journalctl -f -u apache ¹.

More useful options

• -k: only kernel messages (hardware, drivers, USB devices), for this boot unless you say otherwise ¹. journalctl -k -b -1 is the previous boot’s kernel log.
• -e: open the pager at the end, the newest messages ¹.
• -n 50: just the last 50 lines; -r: newest first ¹.
• -x: add explanation text to messages where the journal’s catalog has one ¹.
• --user: your own user services’ logs (lesson 3).

They combine: journalctl -b -1 -p err -u ssh is errors from SSH during the previous boot.

A worked example

Say the printer stopped working.

1. Is the service healthy? systemctl status cups. If it’s failed, the last lines may already say why.
2. What did it log? journalctl -b -u cups -e jumps to its newest messages this boot.
3. Did the hardware show up? journalctl -f -k, then unplug and replug the USB cable: the kernel logs the device arriving, or doesn’t.
4. Anything else complaining? journalctl -b -p err --since "10 minutes ago".

Copy the exact error message into a web search with your Ubuntu version. Exact messages find answers; descriptions like “printer broken” don’t.

How much space it takes

me@garden-laptop:~$ journalctl --disk-usage
me@garden-laptop:~$ sudo journalctl --vacuum-time=4weeks

--disk-usage shows the total size of the journal files; --vacuum-time deletes archived ones older than the time given ¹. journald limits its own size by default, to at most 10% of the file system and never more than 4 GB, so this is rarely needed; the limits can be changed in /etc/systemd/journald.conf ³.

Some programs still write their own text logs under /var/log, such as dpkg.log and the unattended-upgrades folder from the last module. ls /var/log shows what’s there, and less or tail -f reads them.

Your turn

So

The journal collects every log, from the kernel, services, and programs systemd runs, in /var/log/journal, kept across reboots. journalctl reads it, and its filters combine: -b this boot, -b -1 the last, -u name one unit, -p err errors and worse, --since and --until for a time range, -f to follow live, -k for the kernel, -e to jump to the end. Members of adm can read it without sudo. Start with systemctl status, then the unit’s journal, then the kernel, and search for exact error messages.