How to Use the journalctl Command in Linux to Filter and Inspect Systemd Logs

Troubleshooting crashing services, boot bottlenecks, hardware errors, and security authentication failures on modern Linux distributions requires reviewing system log entries. In older SysVinit architectures, administrators had to comb through separate, uncoordinated plain-text files scattered across /var/log/syslog, /var/log/auth.log, and /var/log/messages using commands like grep and tail. Modern distributions utilizing the systemd init system consolidate all system, kernel, and service logging into an indexed, binary journal managed by systemd-journald. To query, filter, and analyze this unified stream, Linux provides the powerful journalctl command-line utility.

Why systemd-journald and journalctl Outperform Legacy Logs

The architecture of systemd-journald introduces significant diagnostic capabilities:

• Centralized Binary Storage: Logs are stored in structured, indexed binary files rather than fragmented plain-text files, enabling instantaneous searches across millions of log entries.
• Rich Metadata Indexing: Every log message automatically captures comprehensive environmental metadata—including the executing systemd unit name, process ID (PID), user ID (UID), timestamp, boot ID, and kernel ring buffer state.
• Automatic Log Rotation and Size Caps: The journal daemon automatically enforces storage quotas, purging the oldest records to prevent log files from exhausting hard drive capacity.
• Tamper-Resistant Security: Binary storage prevents simple line modification, and optional Forward Secure Sealing (FSS) protects log integrity against malicious alteration.

Basic journalctl Usage and Pager Navigation

Running the command without arguments prints the entire journal from the oldest recorded boot:

journalctl

The output pipes into your system’s default terminal pager (typically less). Navigate using:

• Spacebar / Page Down: Advance one screen.
• b / Page Up: Move back one screen.
• /pattern: Search forward for text.
• q: Exit the viewer.

Filtering Logs by Specific systemd Service Units (-u Flag)

The most common administrative task is inspecting logs for a specific application or background daemon (such as Nginx, Apache, SSH, or Docker). Use the -u (unit) argument:

To inspect logs for the SSH daemon:

journalctl -u ssh

(On RHEL/CentOS/Fedora, the service name is typically sshd).

To inspect logs for the Nginx web server:

journalctl -u nginx

You can combine multiple units to trace interactions between dependent services:

journalctl -u nginx -u php8.3-fpm

Filtering by Boot Session (-b Flag)

When debugging an issue that occurred prior to an unexpected system crash or reboot, filtering by boot cycle isolates the relevant time frame:

1. View Logs from the Current Boot

journalctl -b

2. View Logs from the Previous Boot Cycle

journalctl -b -1

(Pass -b -2 for two boots ago, -b -3 for three boots ago, and so forth).

3. List All Recorded Boot Sessions

journalctl --list-boots

Displays an indexed list of every reboot on the system along with unique boot IDs and precise start/end timestamps.

Filtering by Time Range (–since and –until Flags)

To isolate events surrounding an incident without scrolling through days of irrelevant output, pass human-readable time constraints:

View logs generated in the last 30 minutes:

journalctl --since "30 min ago"

View logs generated today:

journalctl --since today

View logs within a precise calendar and time window:

journalctl --since "2026-10-10 14:00:00" --until "2026-10-10 16:30:00"

Filtering by Severity and Priority (-p Flag)

Linux logs use standard Syslog priority levels ranging from 0 (Emergency) to 7 (Debug). Use the -p flag to hide mundane informational chatter and display only critical errors:

Priority Level	Severity Name	Description
0	emerg	System is unusable / complete kernel panic
1	alert	Action must be taken immediately
2	crit	Critical hardware or filesystem conditions
3	err	Non-fatal runtime errors and failures
4	warning	Warning conditions that may precede errors
5	notice	Normal but significant conditions
6	info	Standard informational notifications
7	debug	Detailed diagnostic messages for developers

To view all errors, critical alerts, and emergencies across the entire system:

journalctl -p err..emerg

Or simply pass the lowest priority you wish to include:

journalctl -p 3 -b

Live Real-Time Log Monitoring (-f Flag)

To monitor new incoming log messages in real time (equivalent to tail -f in traditional Unix):

journalctl -f -u nginx

Press Ctrl + C to exit live monitoring.

Viewing Kernel Ring Buffer Messages (-k Flag)

To diagnose hardware detection, USB device insertions, or graphics driver faults without launching dmesg:

journalctl -k -b

Checking Journal Disk Storage and Vacuuming Old Logs

To check how much hard drive space system logs are currently consuming:

journalctl --disk-usage

To clean up excess logs and reclaim disk space:

Purge logs older than 14 days:

sudo journalctl --vacuum-time=14d

Cap total journal storage size to 500 MB:

sudo journalctl --vacuum-size=500M

Frequently Asked Questions

Why does journalctl show logs from the current boot only?

By default on some minimal Linux installations, systemd-journald is configured to store logs purely in RAM (/run/log/journal), wiping them upon reboot. To enable persistent logging across reboots, edit /etc/systemd/journald.conf, set Storage=persistent, and restart the service via sudo systemctl restart systemd-journald.

Can regular non-root users view system logs with journalctl?

By default, unprivileged users can only view logs generated by their own user services. To grant a user permission to view system-wide logs without giving full sudo access, add them to the systemd-journal group: sudo usermod -aG systemd-journal <username>.

Can I export journalctl logs as structured JSON?

Yes. Pass the -o json-pretty or -o json argument: journalctl -u nginx -n 5 -o json-pretty. This output is ideal for parsing with jq or forwarding to log aggregators like Elasticsearch or Grafana Loki.