Use journalctl to Inspect and Manage systemd Logs

Query, filter, follow, export, retain, and troubleshoot systemd journal logs with journalctl.

journalctl reads the structured logs collected by systemd-journald. It can search service, kernel, boot, user-session, and application messages without manually opening separate text log files.

Official references:

Access the Journal

Run journalctl without arguments to display every journal entry available to the current user, starting with the oldest entry.

journalctl

Most distributions restrict access to system-wide logs. Use sudo when diagnosing system services, or use --user for services in the current user’s systemd session.

sudo journalctl
journalctl --user
journalctl --user -u syncthing.service

Output normally opens in a pager. Press Space or Page Down to move forward, b to move backward, / to search, and q to quit. Add --no-pager when redirecting output or using the command in a script.

sudo journalctl --no-pager

Read Recent Messages

Jump to the end of the journal.

sudo journalctl -e

Display the newest entries first.

sudo journalctl -r

Show the last 10 entries, which is the default when -n has no value.

sudo journalctl -n

Show the last 50 entries.

sudo journalctl -n 50

Follow new messages in real time. Press Ctrl+C to stop.

sudo journalctl -f

-x adds explanatory text from the systemd message catalog when a matching explanation exists. It is useful during interactive troubleshooting, but omit it when attaching raw logs to a bug report.

sudo journalctl -xe

Filter by Boot

List the boots retained in the journal, including their relative indexes and boot IDs.

sudo journalctl --list-boots

Show messages from the current boot.

sudo journalctl -b

Show messages from the previous boot.

sudo journalctl -b -1

Use a boot ID from --list-boots when a relative index could be ambiguous.

sudo journalctl -b 0123456789abcdef0123456789abcdef

Show kernel messages from the current boot. The -k option implies -b.

sudo journalctl -k

Show kernel messages from the previous boot.

sudo journalctl -k -b -1

Filter by Time

--since and --until accept complete timestamps and convenient relative expressions.

sudo journalctl --since "2026-09-24 09:00:00"
sudo journalctl --since "20 minutes ago"
sudo journalctl --since today
sudo journalctl --since yesterday --until today
sudo journalctl --since "2026-09-23" --until "2026-09-24 03:00"
sudo journalctl --since 09:00 --until "1 hour ago"

Add --utc when logs from multiple time zones must use a consistent timestamp.

sudo journalctl --since today --utc

Filter by Service

Show every available message for a systemd unit.

sudo journalctl -u nginx.service

Limit a unit to the current boot or a time period.

sudo journalctl -u nginx.service -b
sudo journalctl -u nginx.service --since today

Follow a service in real time and start with its last 50 messages.

sudo journalctl -u nginx.service -n 50 -f

Display messages for either of two units. Repeated -u filters are alternatives, so an entry matching either unit is shown.

sudo journalctl -u nginx.service -u php8.3-fpm.service --since today

The common troubleshooting form below jumps to the newest messages, adds catalog explanations, and limits the result to one unit.

sudo journalctl -xeu nginx.service

Filter by Priority

Journal priorities use the standard syslog levels.

Number Name Meaning
0 emerg System is unusable
1 alert Immediate action is required
2 crit Critical condition
3 err Error condition
4 warning Warning condition
5 notice Significant normal event
6 info Informational message
7 debug Debug message

A single priority includes that level and every more severe level. This command shows err, crit, alert, and emerg entries from the current boot.

sudo journalctl -p err -b

Use a range when you need exact boundaries. This command shows only messages whose priority is exactly err.

sudo journalctl -p err..err -b

Show warnings and more severe messages for one service since the start of the current boot.

sudo journalctl -u nginx.service -p warning -b

Search Message Text

Use --grep or -g to match the MESSAGE field with a regular expression.

sudo journalctl -b -g 'failed|error|timeout'
sudo journalctl -u nginx.service --since today -g 'upstream.*timed out'

An all-lowercase pattern is matched without regard to case. Set the behavior explicitly when capitalization matters.

sudo journalctl -b -g 'ERROR' --case-sensitive=yes

Filter by Structured Fields

Journal entries contain fields such as process ID, user ID, executable path, command name, transport, and systemd unit. Inspect all fields in matching entries with verbose output.

sudo journalctl -u nginx.service -n 1 -o verbose

Filter by process ID, user ID, command name, or executable path.

sudo journalctl _PID=1
sudo journalctl _UID=33 --since today
sudo journalctl _COMM=sshd
sudo journalctl _EXE=/usr/bin/bash

List the field names present in the journal or the known values for a specific field.

sudo journalctl --fields
sudo journalctl --field=_SYSTEMD_UNIT
sudo journalctl --field=SYSLOG_IDENTIFIER

Matches for different fields are combined with AND. This example requires both the specified unit and process ID.

sudo journalctl _SYSTEMD_UNIT=nginx.service _PID=1234

Multiple matches for the same field are combined with OR. This example returns entries from either service.

sudo journalctl _SYSTEMD_UNIT=nginx.service _SYSTEMD_UNIT=php8.3-fpm.service

Filter messages by the syslog identifier recorded by an application.

sudo journalctl -t sshd --since today

Choose an Output Format

Use ISO 8601 timestamps with microsecond precision.

sudo journalctl -u nginx.service -o short-iso-precise

Print only message text without timestamps or metadata.

sudo journalctl -u nginx.service -o cat

Produce one JSON object per journal entry for scripts and log processors.

sudo journalctl -u nginx.service -b -o json --no-pager

Use formatted JSON for manual inspection.

sudo journalctl -u nginx.service -b -o json-pretty

Limit structured output to selected fields.

sudo journalctl -u nginx.service -o json --output-fields=__REALTIME_TIMESTAMP,PRIORITY,_SYSTEMD_UNIT,MESSAGE --no-pager

Export Logs to a File

Save one service’s messages from today as plain text.

sudo journalctl -u nginx.service --since today -o short-iso-precise --no-pager > nginx-today.log

Save warnings and errors from the current boot.

sudo journalctl -b -p warning -o short-iso-precise --no-pager > boot-warnings.log

Use the journal export format when the structured fields must be preserved for transfer or later processing.

sudo journalctl -b -o export --no-pager > current-boot.journal-export

Remember that logs can contain hostnames, usernames, IP addresses, environment details, command arguments, and application data. Review exported files before sharing them.

Check and Reduce Disk Usage

Display the combined size of active and archived journal files.

sudo journalctl --disk-usage

Vacuum operations remove archived journal files. Rotate active files first so the cleanup can reclaim as much eligible data as possible.

sudo journalctl --rotate --vacuum-size=1G
sudo journalctl --rotate --vacuum-time=30days

The following command retains no more than 10 archived journal files after rotation.

sudo journalctl --rotate --vacuum-files=10

Vacuuming is immediate maintenance, not a permanent retention policy. Configure limits in journald.conf for ongoing control.

Enable Persistent Logs and Set Retention Limits

With the default Storage=auto, journald stores persistent logs under /var/log/journal when that directory exists; otherwise it uses volatile storage under /run/log/journal, which is lost at reboot.

Create a drop-in configuration rather than editing the vendor file.

sudo mkdir -p /etc/systemd/journald.conf.d
sudoedit /etc/systemd/journald.conf.d/retention.conf
[Journal]
Storage=persistent
Compress=yes
SystemMaxUse=1G
SystemKeepFree=2G
MaxRetentionSec=30day

Restart journald and flush any eligible runtime entries to persistent storage.

sudo systemctl restart systemd-journald
sudo journalctl --flush
sudo journalctl --disk-usage

SystemMaxUse limits journal usage, while SystemKeepFree reserves space for the rest of the filesystem. Journald follows whichever condition is reached first. Only archived files are removed when enforcing limits, so total usage can temporarily exceed the configured maximum while the active file remains open.

Verify Journal Integrity

Check journal files for internal consistency.

sudo journalctl --verify

A verification failure may indicate an incomplete write, storage corruption, or a damaged copied journal. Preserve the affected files before attempting recovery if they are needed for an investigation.

Read Logs from Another System

Read journal files copied into a directory without merging them into the local journal.

sudo journalctl --directory=/mnt/recovered/var/log/journal

Read a particular journal file or a quoted file pattern.

sudo journalctl --file='/mnt/recovered/var/log/journal/*/*.journal'

Troubleshooting Recipes

A Service Failed to Start

Check its current state, then inspect warnings and errors from the current boot.

sudo systemctl status nginx.service --no-pager
sudo journalctl -u nginx.service -b -p warning -n 100 --no-pager

A Problem Happened During the Previous Boot

List retained boots and inspect the previous boot from newest to oldest.

sudo journalctl --list-boots
sudo journalctl -b -1 -p warning -r

A Kernel or Hardware Error Is Suspected

Inspect kernel warnings from the current boot.

sudo journalctl -k -p warning -b

A Problem Must Be Reproduced Live

Start a filtered follow session, reproduce the problem, and stop the command with Ctrl+C.

sudo journalctl -u nginx.service -n 50 -f

Older Boots Are Missing

Check the boot list and storage mode. If /var/log/journal does not exist and Storage=auto is in effect, logs are probably volatile and disappear at reboot.

sudo journalctl --list-boots
sudo test -d /var/log/journal && echo persistent || echo volatile
sudo systemd-analyze cat-config systemd/journald.conf
Licensed under CC BY-NC-SA 4.0
Last updated on Thursday, September 24, 2026
comments powered by Disqus