A security-focused guide to journalctl — covering authentication log queries, sudo audit trails, service failure investigation, and tamper-evident journal sealing for incident response.
What is journalctl?
The journalctl command queries the systemd journal — a structured, binary log database that collects output from all systemd-managed services, the kernel, and the system boot process. Unlike plain-text log files, the journal stores metadata alongside log messages: exact timestamps with millisecond precision, service unit names, PIDs, UIDs, and priority levels. For security analysis, this structure enables precise queries — filtering by service unit, time range, priority level, or specific user — that would require complex grep pipelines against traditional syslog files. journalctl is the primary log analysis tool on any modern Linux distribution using systemd, which includes Ubuntu 16.04+, Debian 8+, CentOS 7+, and RHEL 7+. It is particularly valuable for correlating events across multiple services within a precise time window during incident response.
Syntax
journalctl [options]
journalctl -u sshd --since '1 hour ago'
journalctl -u sudo --since '24h ago'
journalctl -p err -b
journalctl --since '2026-03-27 00:00:00' --until '2026-03-27 23:59:59'
journalctl -fThe -u flag filters by systemd unit name. --since and --until accept human-readable time expressions or ISO timestamps. -p filters by priority level (0=emerg, 1=alert, 2=crit, 3=err, 4=warning, 5=notice, 6=info, 7=debug). -b limits output to the current boot. -f follows the journal in real-time like tail -f.
Key Options and Flags
| Flag / Parameter | Description | Security Note |
|---|---|---|
-u unit | Filter log entries by systemd service unit name (e.g., sshd, nginx, sudo) | Use -u sshd and -u sudo as the first queries in any authentication-related investigation |
--since / --until | Time range filter — accepts '24h ago', 'yesterday', or ISO timestamps | Always scope investigations to a specific time window to reduce noise and focus on the incident timeline |
-p priority | Filter by syslog priority: err, warning, crit, emerg | Start any health check with -p err to identify all service errors since last boot |
-b [offset] | Limit to entries from the current (-b) or Nth previous (-b -1, -b -2) boot | An unexpected reboot is itself a security event — compare -b 0 and -b -1 to identify what happened |
-f | Follow mode — stream new entries as they arrive | Use during active incident response to monitor real-time authentication attempts |
-o json | Output as JSON — exposes all structured metadata fields for programmatic analysis | — |
--no-pager | Disable the pager — required for piping output to grep, awk, or other tools | — |
Common Use Cases
Extract All sudo Invocations in the Last 24 Hours
Sudo usage logs are essential for privilege audit trails. Every time a user runs sudo, the journal records the username, the command executed, whether it succeeded, and the timestamp. Reviewing this log reveals unexpected privilege usage, off-hours administrative activity, and commands that should not have been run with root.
journalctl -u sudo --since '24h ago' --no-pager
journalctl -u sudo --since '24h ago' --no-pager | grep -E '(COMMAND|FAILED)'Audit SSH Authentication Events
The SSH daemon logs all authentication attempts — successful, failed, and refused — to the journal. During an investigation into unauthorized access, querying sshd logs gives a precise timeline of who authenticated, from which source IP, using which method (password vs. key), and which account they targeted.
journalctl -u sshd --since '7 days ago' --no-pager | grep -E '(Accepted|Failed|Invalid|Disconnected)'
journalctl -u sshd --since '1 hour ago' -fInvestigate Service Failures Around a Security Incident
Service crashes, OOM kills, and segfaults often correlate with exploitation attempts. Reviewing all error-level events in the journal around the time of a suspected incident can reveal what the attacker did to the system and which services were affected or disabled.
journalctl -p err --since '2026-03-27 00:00' --until '2026-03-27 23:59' --no-pager
journalctl -p crit -b --no-pagerSecurity Relevance: Structured Logs as Audit Evidence
The systemd journal’s structured format provides significant advantages over plain-text syslog for security investigations: timestamps cannot be falsified by a user-space process because the journal daemon stamps entries on receipt; metadata fields like UID, PID, and unit name are populated by the kernel and cannot be spoofed by the logging process; and binary storage makes simple text-editing tampering largely ineffective. For compliance requirements, journald supports Forward Secure Sealing (FSS) via journalctl --setup-keys — a cryptographic mechanism that generates a verification key and detects retroactive log modification. Even without FSS, the structured journal is significantly more tamper-evident than a plain auth.log file that any root process can truncate, overwrite, or silently modify. For high-assurance environments, forward audit logs to a separate, immutable logging server to prevent any local tampering by a compromised host.
- journalctl output is only as complete as journald's retention configuration — check Storage= and SystemMaxUse= in /etc/systemd/journald.conf
- An attacker with root access CAN delete or corrupt the journal files directly from /var/log/journal — this is why off-host log shipping matters
- journalctl -f during an active incident can reveal attacker activity in real-time, but the attacker may also notice your monitoring
- On systems without persistent journal storage (Storage=volatile), journal data is lost at reboot — verify your configuration immediately
- The absence of expected log entries is itself suspicious — gaps in the journal timeline may indicate tampering or log clearing
Practical Examples
Reconstruct authentication timeline for a suspected account compromise
journalctl -u sshd --since '7 days ago' --no-pager | grep 'targetuser' | grep -E '(Accepted|Failed|session opened|session closed)'Narrows the sshd journal to a specific username and the most security-relevant events: successful authentications, failures, and session open/close events. This reconstructs the complete access timeline for the account under investigation.
Monitor authentication attempts in real-time during an active attack
journalctl -u sshd -f --no-pager | grep --line-buffered 'Failed password'Follows the SSH daemon journal in real-time, filtering only for failed password attempts. Useful during an active brute force attack to monitor the source IPs and rate, and to verify that fail2ban is triggering bans correctly.
Export all security-relevant events to a file for forensic preservation
journalctl --since '2026-03-25 00:00' --until '2026-03-28 00:00' -o json-pretty > /tmp/journal_export_$(date +%Y%m%d).jsonExports the full journal for a specific date range in structured JSON format. This creates a forensic-grade evidence file that preserves all metadata. Store this file off-server immediately — on compromised systems, evidence can be destroyed at any time.
Troubleshooting Common Issues
Problem: journalctl output only goes back a few days — older events are missing
Solution: The journal is size-limited. Check journalctl --disk-usage and review /etc/systemd/journald.conf for SystemMaxUse= and SystemKeepFree= settings. Increase retention limits or implement log forwarding to a remote syslog server for long-term retention.
Problem: journalctl -u sshd shows no entries even though SSH is running
Solution: The unit name may be ssh instead of sshd on some distributions (notably Ubuntu). Try journalctl -u ssh. Also verify sshd is managed by systemd with systemctl status sshd ssh 2>/dev/null.
Problem: Journal data missing after a system crash or hard reboot
Solution: If Storage=auto (default) and /var/log/journal does not exist, the journal is written to /run/log/journal and lost on reboot. Create the persistent storage directory: mkdir -p /var/log/journal && systemd-tmpfiles --create --prefix /var/log/journal and restart journald.
Summary
The journalctl command provides structured, metadata-rich access to the systemd journal — the primary log source on all modern Linux servers. Its filtering capabilities make it far more efficient than text-based grep against flat log files for security investigations. Develop standard queries for authentication events, sudo usage, and service failures, and run them as the first step in any security incident timeline reconstruction.
- Start every SSH investigation with
journalctl -u sshd --since '24h ago'— it gives the complete authentication picture - Export journal data to JSON off-server immediately when an incident is detected — evidence can be destroyed
- Configure persistent journal storage and increase retention limits — default configurations often lose data after a few days
Related Commands
last for login history • lastb to audit failed login attempts • grep auth.log for rapid log triage • ausearch for kernel audit log analysis
Are Your Server Logs Centralized and Monitored for Security Events?
INTRAM configures centralized log management, persistent journal storage, and real-time alerting on authentication anomalies for every managed Linux server.
Get Managed Monitoring