Linux command: journalctl

1. The Basics

The job of journalctl is to read and filter the systemd journal. The journal is a structured log kept by a background service called systemd-journald. Every message from the kernel, from systemd itself, and from every service it starts flows into that journal. journalctl is the window you look through to see it.

This matters because it changes how you troubleshoot. On an old system you had to know which file to open: /var/log/syslog for general messages, /var/log/auth.log for logins, a separate file per application. With the journal, you ask one tool and narrow down from there:

One record for the whole system, and one command to question it: by service, by boot, by time, or by how serious the message is.

This article starts with the plainest use and builds up step by step to filtering by unit and boot, priority levels, the structured fields under each line, output formats, and how to keep the journal from filling your disk. By the end, reading logs on a systemd machine will feel routine.

The right mental model: the journal is a database of log entries, not a text file. journalctl is the query tool. Every line you see on screen is really a record with many fields, and the plain output is just one friendly view of it.

1.1 The Simplest Possible Use

Run journalctl with no options and it prints the entire journal, oldest first, into a pager:

$ journalctl
-- Journal begins at Wed 2024-05-01 09:12:04 CEST. --
May 01 09:12:04 xps kernel: Linux version 6.8.0-50-generic ...
May 01 09:12:04 xps kernel: Command line: BOOT_IMAGE=/boot/vmlinuz ...
...

The output opens in less, so you can scroll, and search with /, just like reading a file. Press q to quit. On a machine that has been running for weeks this can be a very long list, which is why the next sections are all about narrowing it down.

1.2 You Usually Need root

A normal user sees only their own user services and, on many systems, a limited view. To read the full system journal, run it with sudo:

$ sudo journalctl

On most distributions, adding your account to the systemd-journal group grants read access to the whole journal without sudo each time. Membership takes effect at your next login.

3. A Short History

To understand journalctl you have to know where it came from, because it replaced a way of logging that had barely changed for decades.

For most of Unix history, logging was done by syslog: a service (such as syslogd or later rsyslog) received messages and appended them as lines of text to files under /var/log. It was simple, human-readable, and easy to process with grep, awk, and friends. Its weakness was structure: a log line was just a string, so filtering by service, user, or exact time meant parsing text and hoping every program formatted its lines the same way.

systemd, first released in 2010 by Lennart Poettering and Kay Sievers, set out to replace the old init system that started services at boot. A couple of years later the project added its own logging service, systemd-journald, and with it the journalctl tool. Instead of plain text, the journal stores each entry as a set of key/value fields in an indexed binary file, so filtering and sorting are built in.

The journal did not fully kill syslog. Many systems run rsyslog alongside the journal, forwarding entries so that classic text files still exist for tools and habits that expect them. But on a default modern install, journalctl is the primary way to read logs. This article is verified against systemd version 255.

5. Moderate Use Cases

5.1 Logs for One Service: -u

This is the single most useful filter. The -u flag (short for unit) limits the output to one systemd unit, such as a web server or database:

$ journalctl -u nginx.service
$ journalctl -u ssh            # the .service suffix is optional

Combine it with the flags you already know to get a sharp, practical view:

$ journalctl -u nginx -n 50      # last 50 lines for nginx
$ journalctl -u nginx -f         # follow nginx live

Instead of hunting for the right log file, you name the service and see exactly its messages, merged in time order.

5.2 Filter by Time: --since and --until

The --since (-S) and --until (-U) options limit the output to a time window. They accept exact timestamps and friendly words:

$ journalctl --since "2026-07-12 09:00:00"
$ journalctl --since "1 hour ago"
$ journalctl --since yesterday --until "09:00"
$ journalctl -u nginx --since today

Words like today, yesterday, and phrases like 10 min ago are understood directly. This is how you answer "what happened around the time the site went down?" without scrolling through days of history.

5.3 Only This Boot: -b

A server may have restarted several times. The -b flag (short for boot) limits the journal to a single boot. With no number it means the current boot:

$ journalctl -b          # everything since the last boot
$ journalctl -b -1       # the previous boot
$ journalctl --list-boots

The last command lists every boot the journal remembers, with an index and a time range:

$ journalctl --list-boots
IDX BOOT ID           FIRST ENTRY                  LAST ENTRY
 -2 8b909d28e49e4884  Sat 2026-06-20 10:20:39 CEST Sat 2026-06-20 15:35:36 CEST
 -1 6f4e7bd5d6ea468f  Sat 2026-06-20 15:36:13 CEST Sat 2026-06-20 16:24:37 CEST
  0 c62bfe02a8b64075  Sun 2026-06-21 13:28:43 CEST Sun 2026-06-21 15:19:26 CEST

The current boot is always 0, and older boots count down with negative numbers. This is how you check "did anything go wrong before the last reboot?".

5.4 Filter by Severity: -p

Not every message matters equally. The -p flag (short for priority) keeps only entries at or above a level of seriousness. The journal uses the eight classic syslog levels:

Ask for a level by name or number, and you get that level and everything more serious:

$ journalctl -p err          # errors, crit, alert, emerg only
$ journalctl -p warning -b    # warnings and worse, this boot

Filtering to err and above is a fast way to cut a noisy log down to the entries that usually deserve attention. You can also give a range in the form FROM..TO to pin the output to a band of levels and leave out the rest:

$ journalctl -p err..alert    # only err, crit, and alert (not emerg, not warning)

5.5 Kernel Messages: -k

The -k flag (short for dmesg, the traditional kernel-message command) shows only messages from the kernel itself, for the current boot:

$ journalctl -k          # like dmesg, but from the journal

This is where you look for hardware trouble: a failing disk, a network card resetting, or an out-of-memory event.

5.6 Investigating a Crash: Boot IDs as Anchors

When you look into an unexpected reboot or a security incident, the boot becomes your unit of investigation, and the Boot ID is what anchors it. Every time the machine starts, the kernel assigns a fresh, unique 32-character identifier, and the journal stamps every entry of that session with it in the _BOOT_ID field. Because the ID is fixed for the whole boot, it identifies a session reliably even if the clock jumps or files are rotated, which the wall-clock time alone cannot promise.

You saw the relative index earlier (-b -1 for the previous boot). For evidence you often want the exact boot instead, named by its ID from --list-boots:

$ journalctl -b 6f4e7bd5d6ea468f9b1cbe30f800c32d    # one exact boot, by its ID

The real power comes from combining the boot filter with the others you already know, to ask a sharp question about a single session. To investigate the boot before a crash:

$ journalctl -b -1 -k -p err       # kernel errors from the previous boot
$ journalctl -b -1 -p err          # all errors and worse, previous boot
$ journalctl -b -1 -u sshd         # who touched ssh before the reboot

This is the everyday shape of log forensics: pick the boot, then narrow by the kernel, a priority, a service, or a time window until only the relevant lines remain. Boot IDs make "what happened during that one session?" a precise query rather than a scroll through a merged timeline.

7. Something Most Users Do Not Know

7.1 Every Line Is Really a Record with Many Fields

The plain journalctl output looks like text, but each entry is stored as a bundle of fields. Ask for the verbose format and one single line unfolds into everything the journal knows about it:

$ journalctl -n 1 -o verbose
Thu 2026-09-24 08:58:47.550521 CEST [s=f6a6...;i=26de0c;b=84ee...]
    PRIORITY=6
    _HOSTNAME=xps
    _UID=0
    _GID=982
    _PID=1249
    _COMM=nordvpnd
    _EXE=/usr/sbin/nordvpnd
    _SYSTEMD_UNIT=nordvpnd.service
    _BOOT_ID=84ee2a04d2c94a348d1a43b1d1c09db4
    SYSLOG_IDENTIFIER=nordvpnd
    MESSAGE=HTTP call finished in 240ms

This is the heart of what makes the journal different from a text log. The program supplied the MESSAGE, and the journal attached the rest automatically: which process, which user, which service, which boot. Because those fields are indexed, filtering by any of them is fast and exact, with no text parsing.

A syslog file remembers the sentence. The journal remembers the sentence, who said it, when, on which boot, from which process, and under which service, all as separate fields you can query.

7.2 The Journal Can Be Volatile: Logs May Vanish on Reboot

Here is a surprise that catches many people out. Whether your logs survive a reboot depends on a directory existing:

• If /var/log/journal/ exists, the journal is persistent: it is written to disk and kept across reboots.
• If that directory does not exist, the journal is volatile: it lives only in memory under /run/log/journal/ and is wiped on every reboot.

On some minimal systems the default is volatile, which means journalctl -b -1 for a past boot returns nothing, because that boot's logs were never saved. The setting is controlled by Storage= in /etc/systemd/journald.conf. To guarantee persistent logs, make sure the directory exists and let journald flush to it:

$ sudo mkdir -p /var/log/journal
$ sudo systemctl restart systemd-journald

This one difference explains a common frustration: "I rebooted to fix it and now the evidence is gone." On a server you care about, persistent storage should always be on.

7.3 Monotonic Timestamps Survive a Clock Change

The timestamps you normally see are wall-clock time, and wall-clock time can jump. When NTP corrects the clock, or an administrator sets it by hand, the ordinary log times shift with it, which can scramble the apparent order of events. The journal also records a monotonic timestamp: seconds since the machine booted, which only ever counts forward. Ask for it with the short-monotonic output format:

$ journalctl -b -o short-monotonic
[   12.345678] xps systemd[1]: Started NetworkManager.
[   15.892134] xps nginx[812]: nginx.service started.
[   18.456201] xps sshd[1123]: Accepted publickey for peter

The number in brackets is the elapsed time since boot. Because it cannot move backwards, it gives a trustworthy order of events even across a clock adjustment, which makes it the format of choice when you reconstruct exactly what happened during a boot or an incident. It pairs naturally with the Boot ID from section 5.6: the Boot ID picks the session, and the monotonic clock fixes the order of events inside it, even when the wall clock cannot be trusted.

7.4 The Journal Can Be Sealed, But It Is Not Encrypted

Two facts about the journal's safety surprise people, and both are worth knowing:

• The journal is not encrypted by default. Binary storage stops casual editing with a text editor, but anyone who can read the files can read the messages. Do not treat it as a place to hide secrets.
• The journal can be tamper-evident. A feature called Forward Secure Sealing (FSS) periodically signs the journal with a key, so that later changes to old entries can be detected. You turn it on by generating a key pair:

$ sudo journalctl --setup-keys      # generate an FSS key pair
$ journalctl --verify               # check the journal for tampering

Sealing does not hide the contents; it proves whether they were altered after the fact. That distinction matters on a machine where the logs may become evidence: FSS answers "has this log been changed?", not "can others read it?".

7.5 Where journalctl Stops, Other Tools Take Over

The journal reads its own store, and that is where it ends. A few neighbours pick up from there:

• systemctl status nginx shows a unit's state and its last few journal lines together, which is often enough to start.
• dmesg reads the kernel ring buffer directly; journalctl -k shows the same messages through the journal.
• rsyslog still writes classic text files in /var/log on many systems, useful for tools that expect them.
• For many machines, a central log collector (such as an ELK or Loki stack) ingests the journal's JSON output so you can search all servers at once.

Knowing this boundary keeps you efficient: journalctl for one machine's history, a collector when you need many machines in one view.

9. Common Mistakes

9.1 Myth versus Reality

9.2 Other Traps to Avoid

• Reading only the current boot by accident. Many examples use -b, which hides older boots. Drop -b, or use -b -1, when you need history from before the last restart.
• Forgetting sudo. As a normal user you may see only part of the journal. Use sudo, or join the systemd-journal group, to read everything.
• Letting the journal fill the disk. If space runs low, clear old entries safely with a vacuum rather than deleting files by hand:

$ sudo journalctl --vacuum-size=500M    # keep at most 500 MB
$ sudo journalctl --vacuum-time=2weeks   # delete entries older than 2 weeks

• Piping to grep when a flag is better. journalctl | grep nginx works but is slow and clumsy. journalctl -u nginx or -g pattern lets the journal filter for you.
• Expecting local time in scripts. Timestamps show your local time zone by default. Add --utc when you need a stable, comparable time across servers.
• Not knowing that journald drops messages under load. To protect itself from a flood, journald rate-limits each service (by default 10000 messages in 30 seconds) and then writes a note that it "Suppressed" the rest. If a very chatty service seems to be missing lines, it may have hit that limit, not failed. Raise RateLimitBurst= in /etc/systemd/journald.conf if you truly need every line.