journalctl: Complete Guide to Linux System Diagnostics

Introduction / Why You Need This

journalctl is a powerful utility for viewing and analyzing the systemd system journal, which replaces traditional log files (e.g., /var/log/syslog). With it, you can:

• Diagnose failures: Find out why a service failed to start or crashed.
• Analyze performance: Track system load, service requests.
• Security: Check for suspicious events (failed logins, changes).
• Monitoring: Keep an eye on operations in real time.

This guide will turn you from a beginner who only knows journalctl | grep error into a confident user who can quickly find the needed information.

Requirements / Preparation

1. Operating system: Any modern Linux distribution with systemd (Ubuntu 20.04+, Debian 10+, CentOS 8+, Fedora 35+, etc.).
2. Access permissions: To view all logs, you need root privileges or membership in the systemd-journal group. Regular users see only their own logs.
   • Add yourself to the group: sudo usermod -aG systemd-journal $USER (requires re-login).
3. Basic knowledge: Comfortable terminal usage, understanding of systemd services (.service).

💡 Tip: If you're working on a server without a GUI, journalctl is your primary diagnostic tool. Knowing its filters will save hours of searching.

Step-by-Step Guide

Step 1: Basic Log Viewing

Simply run journalctl — you'll see the entire journal, starting from the earliest entry. This is analogous to cat /var/log/syslog, but with filtering capabilities.

journalctl

By default, it uses the less pager. Navigation:

• Space — next page.
• b — previous page.
• q — exit.

Important: If the output is too large, apply filters immediately (see below).

Step 2: Time-Based Filtering

Often you need logs from the last few hours or days. Use:

• -S (--since) — start time.
• -U (--until) — end time.

Time format is flexible:

# Logs for today
journalctl --since today

# Last 2 hours
journalctl --since "2 hours ago"

# For a specific day (from 00:00 to 23:59)
journalctl --since "2026-02-14" --until "2026-02-15"

# Down to the minute
journalctl --since "2026-02-14 09:30:00" --until "2026-02-14 10:00:00"

Step 3: Service (Unit) Filtering

If an issue involves a specific service (e.g., nginx, docker), filter by its name:

journalctl -u nginx.service

Short form: journalctl -u nginx (the .service extension is optional).

Can be combined with time filters:

journalctl -u docker.service --since "1 hour ago"

Step 4: Priority (Log Level) Filtering

The systemd journal classifies messages by priority (from most critical to debug):

Priority filter:

# Only errors and higher (err, crit, alert, emerg)
journalctl -p err

# All except debug (info and higher)
journalctl -p info

# Only warnings
journalctl -p warning

Step 5: Real-Time Monitoring

To see new entries as they appear (like tail -f), use the -f flag:

journalctl -f

Combinations:

• With service filter: journalctl -u ssh.service -f
• With priority filter: journalctl -p err -f
• With time filter (shows new entries after specified time): journalctl -S "10:00" -f

Step 6: Text and Regex Search

For searching within entries, use grep-like flags:

• -k or --dmesg — show only kernel messages (like dmesg).
• -g <pattern> — search by regex (requires systemd ≥ 237).

# Search for the word "failed"
journalctl | grep failed

# More efficiently: journalctl can filter itself
journalctl -g "failed to start"

# Search by IP address (regex)
journalctl -g "192\.168\.1\.\d+"

Step 7: Viewing Other Users' Logs and Boot Messages

• Boot logs: journalctl -b (current boot), journalctl -b -1 (previous boot).
• Logs of a specific unit for the current boot: journalctl -u ssh.service -b.
• Logs of a specified PID: journalctl _PID=1234.
• Logs of a specified executable file: journalctl /usr/bin/nginx.

Step 8: Journal Size Management (Cleanup)

By default, the journal can take up significant space (up to 10% of disk). Management:

1. View current usage:

   journalctl --disk-usage
   

2. Clean up old entries:

   # Delete entries older than 7 days
   journalctl --vacuum-time=7d
   
   # Keep no more than 500M
   journalctl --vacuum-size=500M
   
   # Delete all logs (caution!)
   journalctl --rotate && journalctl --vacuum-time=1s
   

3. Set permanent limits (see "Potential Issues" section).

Verification

After completing the steps, you should be able to:

1. Find a service error:

   journalctl -u nginx.service -p err --since "10 minutes ago"
   

   
   Output should contain lines with Failed or error.
2. Track system boot:

   journalctl -b -1 -p warning
   

   
   Shows warnings from the previous boot (useful for boot issues).
3. Control size:

   journalctl --disk-usage
   

   
   Value should be reasonable (e.g., < 500M on a server).

If you can perform these three actions — you've mastered the guide.

Potential Issues

Issue 1: "No journal files were found" or empty output

Cause: Journal is disabled or stored only in RAM (Storage=volatile in /etc/systemd/journald.conf). Solution:

1. Check config: cat /etc/systemd/journald.conf | grep Storage.
2. If Storage=volatile, change to persistent (store on disk).
3. Restart: sudo systemctl restart systemd-journald.

Issue 2: Insufficient permissions to view logs

Cause: Current user not in systemd-journal group. Solution: Add user to group and re-login:

sudo usermod -aG systemd-journal $USER
newgrp systemd-journal  # or reopen terminal

Issue 3: Journal takes up entire disk

Cause: No configured limits, rotation logic failed. Solution:

1. Immediately clean: sudo journalctl --vacuum-size=100M.
2. Configure limits in /etc/systemd/journald.conf:

   [Journal]
   SystemMaxUse=500M
   SystemKeepFree=1G
   MaxRetentionSec=30d
   

3. Restart systemd-journald.

Issue 4: Can't find needed entry due to huge log volume

Solution: Always use filter combinations! For example:

# nginx errors in last 30 minutes
journalctl -u nginx -p err --since "30 minutes ago"

# All network-related entries today
journalctl -g "network" --since today

Issue 5: Want to see logs in classic files (/var/log/syslog)

Cause: By default, systemd may duplicate logs to /var/log/syslog (via systemd-journald → rsyslog), but this is configurable. Solution: Ensure rsyslog is installed and configured to accept messages from the journal. Usually works out-of-the-box on Debian/Ubuntu. For pure journal-only distributions (e.g., some Fedora versions), classic files may be absent.

Issue 6: Need to save logs for developers

Solution: Export to a text file with filtering:

journalctl -u myapp.service --since "2026-02-14" > myapp_logs.txt

Or in binary format (for full compatibility):

journalctl --output=export -u myapp.service > myapp_logs.journal

Issue 7: journalctl is slow with large log volume

Solution: Use --no-pager to disable less, or filter immediately:

journalctl --no-pager -u nginx -p err --since "1h"