journalctl Command - Linux Reference

Overview

journalctl is the primary tool for querying and viewing logs from systemd's journal service (journald). Unlike traditional syslog files stored in /var/log, journald uses a binary format that provides structured logging with rich metadata, powerful filtering, and efficient storage. The journal captures boot logs, service messages, kernel logs, audit logs, and application output with consistent formatting and reliable timestamps.

Why journald Matters

Traditional syslog has limitations: text-based format, inconsistent timestamps, difficult correlation of related events, and unreliable message capture during early boot or system crashes. Systemd's journal addresses these issues with binary storage, microsecond timestamps, automatic metadata tagging, structured data support, and crash-resistant logging.

Log Priority Levels

Priority	Value	Description	Typical Use
emerg	0	System is unusable	Panic conditions, critical hardware failure
alert	1	Action must be taken immediately	Corruption detected, immediate intervention required
crit	2	Critical conditions	Hard device errors, critical resource exhaustion
err	3	Error conditions	Non-critical errors, failed operations
warning	4	Warning conditions	Potential issues, deprecated features
notice	5	Normal but significant	Important events, service starts/stops
info	6	Informational messages	Routine information, status updates
debug	7	Debug messages	Detailed diagnostic information

Example 1: View All Journal Entries

                    $ journalctl

                    $ journalctl | less      # Explicitly use less pager

                    $ journalctl --no-pager  # Disable paging (dump all output)

Shows all journal entries from all boots, all services, and all priorities. Output is automatically paged using less, allowing you to scroll, search, and navigate.

Navigation in less:

Space/Page Down: Scroll forward one page
b/Page Up: Scroll backward one page
/pattern: Search forward for pattern
?pattern: Search backward for pattern
n/N: Next/previous search match
G: Go to end of log
g: Go to beginning of log
q: Quit

Note: Without filters, this can display millions of entries. The journal grows continuously, so consider using time filters, unit filters, or boot filters to narrow results.

Example 2: Follow Journal in Real-Time

                    $ journalctl -f

                    $ journalctl --follow

                    $ journalctl -f -u nginx    # Follow specific service

                    $ journalctl -f -p err      # Follow only errors and above

Similar to "tail -f", displays new journal entries as they are added. Continuously shows the last 10 lines and appends new entries in real-time.

Use cases:

Monitor system in real-time during troubleshooting
Watch service behavior after configuration changes
Track application errors as they occur
Observe boot process or service restart

Tip: Combine -f with other filters (unit, priority, boot) to focus on specific events. Press Ctrl+C to stop following.

Example 3: View Logs for Specific Service

                    $ journalctl -u nginx

                    $ journalctl -u sshd.service

                    $ journalctl -u httpd --since today

                    $ journalctl -u mysql -n 100    # Last 100 entries

The -u (--unit) option filters journal entries to show only messages from a specific systemd unit (service, socket, mount, timer, etc.).

Common services to monitor:

sshd: SSH login attempts and authentication issues
nginx/apache2: Web server errors and access issues
mysql/postgresql: Database startup problems and queries
NetworkManager: Network connectivity issues
docker: Container management events

Note: You can omit the .service suffix for service units. "journalctl -u sshd" and "journalctl -u sshd.service" are equivalent.

Example 4: Time-Based Filtering

                    $ journalctl --since "2025-11-01 10:00:00"

                    $ journalctl --since "2 hours ago"

                    $ journalctl --since today

                    $ journalctl --since yesterday --until "1 hour ago"

                    $ journalctl --since "10 min ago" -u apache2

                    $ journalctl --since 09:00 --until "1 hour ago"

Filter logs by time range using natural language or specific timestamps. Supports ISO 8601 format and relative time specifications.

Supported time formats:

Absolute: "2025-11-01 14:30:00", "2025-11-01", "14:30"
Relative: "10 min ago", "2 hours ago", "3 days ago", "1 week ago"
Named: "today", "yesterday", "tomorrow"
Special: "now", "@1234567890" (Unix timestamp)

Best Practice: When troubleshooting an incident, start with a narrow time window around when the problem occurred. This dramatically reduces output volume and improves performance.

Example 5: Filter by Priority Level

                    $ journalctl -p err

                    $ journalctl -p 3          # Same as err (priority 3)

                    $ journalctl -p warning..err  # Range: warning through err

                    $ journalctl -p crit --since today

                    $ journalctl -u sshd -p notice

The -p (--priority) option filters messages by severity. Specifying a priority level shows that level and everything more severe.

Examples:

-p err: Shows err, crit, alert, and emerg
-p warning: Shows warning and above (includes err, crit, alert, emerg)
-p info: Shows everything except debug
-p emerg: Shows only the most critical messages

⚠️ Important: Default system behavior varies. Some systems log at info level, others at notice. Debug messages are typically not logged unless explicitly enabled in journald.conf.

Example 6: View Specific Boot Logs

                    $ journalctl -b

                    $ journalctl -b 0           # Current boot (same as -b)

                    $ journalctl -b -1          # Previous boot

                    $ journalctl -b -2          # Two boots ago

                    $ journalctl --list-boots   # Show all available boots

The -b (--boot) option filters logs to a specific system boot. Each boot is assigned a sequential boot ID.

Understanding boot IDs:

0 or -b alone: Current boot
-1: Previous boot (most recent before current)
-2, -3, etc.: Earlier boots in reverse chronological order
Boot ID hash: Specific boot by unique identifier

Troubleshooting crashes: When the system crashed and rebooted, use "journalctl -b -1" to see logs from the problematic boot. This is crucial for diagnosing kernel panics, hardware failures, or service crashes that caused the reboot.

Example 7: Show Boot-Related Messages

                    $ journalctl -b -u systemd-journald

                    $ journalctl -k                # Kernel messages only

                    $ journalctl -k -b            # Kernel messages for current boot

                    $ journalctl -b | grep -i error

The -k (--dmesg) option shows only kernel messages, equivalent to the dmesg command but with better formatting and filtering capabilities.

Boot troubleshooting workflow:

Check kernel messages: journalctl -k -b
Look for hardware errors: journalctl -k -b | grep -i error
Check service startup: journalctl -b | grep -i failed
Review time to target: systemd-analyze blame

Example 8: Reverse Order and Limit Output

                    $ journalctl -r

                    $ journalctl -n 50           # Show last 50 entries

                    $ journalctl -n 100 -r       # Last 100 entries, newest first

                    $ journalctl -u nginx -n 20  # Last 20 nginx entries

                    $ journalctl --lines=200     # Long form of -n

The -r (--reverse) option displays entries in reverse chronological order (newest first). The -n (--lines) option limits output to the most recent N entries.

Why reverse order matters:

Most recent events are usually most relevant
Avoid scrolling through thousands of older entries
Quick access to latest errors without paging
Efficient troubleshooting workflow

Quick check: "journalctl -u servicename -n 20 -r" gives you the last 20 entries for a service with newest first - perfect for quick status checks.

Example 9: Output Formats (JSON, Verbose, Cat)

                    $ journalctl -o json

                    $ journalctl -o json-pretty

                    $ journalctl -o verbose      # Show all metadata fields

                    $ journalctl -o cat          # Show only message field

                    $ journalctl -o short-iso    # ISO timestamp format

                    $ journalctl -o export       # Binary export format

The -o (--output) option controls output formatting. Different formats reveal different levels of metadata and structure.

Format descriptions:

short: Default format with timestamp and message
json: One JSON object per line (machine-readable)
json-pretty: Formatted JSON with indentation
verbose: Shows ALL metadata fields (very detailed)
cat: Only message content (for piping/parsing)
short-iso: ISO 8601 timestamps
short-precise: Microsecond precision
export: Binary format for journal file export

                    # Example JSON output with metadata

{

  "__CURSOR": "s=...",

  "__REALTIME_TIMESTAMP": "1699382400000000",

  "_HOSTNAME": "webserver",

  "_SYSTEMD_UNIT": "nginx.service",

  "PRIORITY": "6",

  "MESSAGE": "nginx started successfully"

}

Example 10: Advanced Filtering and Field Matching

                    $ journalctl _PID=1234

                    $ journalctl _UID=1000 --since today

                    $ journalctl _COMM=sshd

                    $ journalctl _SYSTEMD_UNIT=nginx.service + _SYSTEMD_UNIT=apache2.service

                    $ journalctl _TRANSPORT=kernel

                    $ journalctl SYSLOG_FACILITY=3  # System daemons

Field matching allows precise filtering based on journal metadata fields. Fields start with underscore for system fields or uppercase for application fields.

Common fields:

_PID: Process ID
_UID: User ID
_GID: Group ID
_COMM: Command name
_EXE: Executable path
_HOSTNAME: System hostname
_TRANSPORT: How message entered journal (kernel, syslog, stdout, journal)
_SYSTEMD_UNIT: Systemd unit name
SYSLOG_FACILITY: Syslog facility code

Operators:

Space between matches: AND logic (all must match)
+ between matches: OR logic (any can match)

                    # Complex example: SSH logs for specific user

$ journalctl _SYSTEMD_UNIT=sshd.service _UID=1000 --since yesterday

# Multiple units (OR logic)

$ journalctl _SYSTEMD_UNIT=nginx.service + _SYSTEMD_UNIT=apache2.service

# Show all available fields

$ journalctl -o verbose -n 1

Disk Usage and Journal Management

                    $ journalctl --disk-usage      # Show current journal size

                    $ journalctl --verify          # Check journal integrity

                    $ sudo journalctl --vacuum-time=2weeks  # Keep only 2 weeks

                    $ sudo journalctl --vacuum-size=500M    # Limit to 500MB

                    $ sudo journalctl --rotate     # Force log rotation

Journal files can grow large over time. Regular maintenance prevents disk space issues.

Journal storage configuration: Edit /etc/systemd/journald.conf

SystemMaxUse=: Maximum disk space
SystemKeepFree=: Minimum free space to maintain
MaxRetentionSec=: Maximum age of entries
MaxFileSec=: Maximum time before rotation

Persistent vs Volatile Storage

By default, journals may be stored in volatile storage (/run/log/journal) and lost on reboot. To enable persistent storage across reboots:

                    $ sudo mkdir -p /var/log/journal

                    $ sudo systemctl restart systemd-journald

Or set Storage=persistent in /etc/systemd/journald.conf

Related Commands and Tools

systemctl: Manage systemd services (status, start, stop, restart)
systemd-analyze: Analyze boot time and service dependencies
dmesg: View kernel ring buffer (journalctl -k is modern alternative)
logger: Add messages to the journal from scripts
systemd-cat: Connect stdout/stderr of command to journal
coredumpctl: View and manage core dumps

Pro Tips for journalctl

Combine filters: Use multiple options together for precise queries
Use time filters first: Narrow by time before adding other filters for better performance
Check previous boot after crash: journalctl -b -1 -p err
Monitor service in real-time: journalctl -u servicename -f
Export for analysis: Use -o json for parsing with jq or Python
Verify journal health: Run --verify periodically to check corruption
Keep archives: Use --vacuum-time to retain history for compliance
Search efficiently: Use field matching instead of grep when possible
Correlation IDs: Use _BOOT_ID to track events across a specific boot
Script integration: journalctl -o cat is perfect for parsing in scripts