What Is journald?
journald is the logging component of systemd, the init system and service manager used by nearly all major Linux distributions today, including Ubuntu, Debian, Fedora, RHEL/CentOS, and Arch. Rather than relying solely on flat text files scattered across /var/log, journald collects log data from the kernel, initrd, standard output/error of services, and syslog into a single, structured, indexed binary format.
Because journald is tightly integrated with systemd, it automatically captures logs from every unit (service) that systemd manages, including startup order, exit codes, and crash signals without requiring administrators to configure individual logging paths. This makes it the default, and often primary, log source on modern distributions, even in setups that also run traditional syslog daemons (like rsyslog) alongside it for long-term archival or remote log shipping.
For website and server administrators, journald is usually the first place to look when a web server, database, or reverse proxy misbehaves, when investigating unauthorized access attempts, or when correlating a security event across multiple services and boot sessions. Its structured, queryable nature makes it far more efficient for troubleshooting and forensics than grepping through plain text log files.
The primary command-line tool used to query journald’s logs is journalctl. The tables below cover the commands and options administrators reach for most often.
Common journalctl Commands
| Command | What it accomplishes |
|---|---|
journalctl |
The baseline command. Dumps the entire journal from oldest to newest entry - useful as a starting point before narrowing your query. |
journalctl -e |
Jumps straight to the end of the log (like tail), so you see the most recent events immediately instead of scrolling through history. |
journalctl -f |
Follows the log in real time, similar to tail -f. Essential when watching a service start up or reproducing a live issue. |
journalctl -r |
Reverses the output so the newest entries appear first - handy for quickly scanning what just happened without paging to the bottom. |
journalctl -k |
Shows only kernel messages (equivalent to dmesg). Useful for diagnosing hardware, driver, or kernel-level security modules like AppArmor/SELinux denials. |
journalctl -b |
Limits output to the current boot session. Great for isolating issues to “since the last reboot” rather than the entire log history. |
journalctl -b -1 |
Shows logs from the previous boot. Critical for diagnosing what caused a crash or unexpected reboot after the fact. |
journalctl --list-boots |
Lists all recorded boot sessions with their IDs and timestamps, so you can target a specific boot with -b. |
journalctl --disk-usage |
Reports how much disk space the journal is currently consuming - important on servers with limited storage. |
journalctl --vacuum-size=500M |
Trims the journal down to a specified size, freeing disk space without disabling logging. A key maintenance command for long-running servers. |
journalctl --vacuum-time=2weeks |
Removes journal entries older than a given time span. Useful for enforcing log retention policies. |
Filtering by Unit, Service, and Time
| Command / Option | What it accomplishes |
|---|---|
journalctl -u nginx |
Filters logs to a single systemd unit (e.g., nginx.service). The fastest way to isolate a specific web server, database, or application’s activity. |
journalctl -u sshd -u nginx |
Combines multiple units in one query, useful for correlating events between related services, like a reverse proxy and its backend app. |
journalctl --since "2026-08-18 09:00" |
Filters entries starting from a specific date/time. Precise time-boxing is essential when investigating an incident with a known start point. |
journalctl --since today |
Uses relative time keywords (today, yesterday, now) for quick, low-effort filtering during routine checks. |
journalctl --since "-1 hour" |
Shows only the last hour of logs - a fast way to check recent activity without specifying exact timestamps. |
journalctl --since "09:00" --until "09:30" |
Bounds a query to a tight time window, ideal for zeroing in on a known incident timeframe, such as a suspected intrusion window. |
journalctl _PID=1234 |
Filters by a specific process ID, useful when you’ve already identified a suspicious or misbehaving process via ps or top. |
journalctl _UID=1000 |
Filters logs generated by a specific user ID - valuable when auditing activity tied to a particular account. |
Filtering by Priority and Content
| Command / Option | What it accomplishes |
|---|---|
journalctl -p err |
Shows only entries at “error” priority or higher, cutting through noise to surface what’s actually broken. |
journalctl -p warning..err |
Filters to a priority range (warning through error), useful for catching degrading conditions before they become full outages. |
journalctl -p crit -b |
Combines priority and boot filters to quickly find critical failures since the last restart - a good first move after an unexpected downtime event. |
journalctl -g "Failed password" |
Greps the journal for a specific pattern, directly useful for spotting brute-force SSH login attempts or other suspicious keyword matches. |
journalctl -u sshd -g "Invalid user" |
Combines unit and pattern filtering to hunt for reconnaissance/brute-force attempts against SSH specifically - a staple in server security triage. |
journalctl _SYSTEMD_UNIT=nginx.service -p err |
Chains a unit filter with a priority filter using journald’s native field syntax for very precise, low-noise queries. |
Output Formatting and Detail
| Command / Option | What it accomplishes |
|---|---|
journalctl -o json-pretty |
Outputs entries as readable JSON, useful when you need to inspect all available structured fields for a log entry, including hidden metadata. |
journalctl -o json |
Outputs compact JSON, ideal for piping into scripts, jq, or external log-processing and SIEM pipelines. |
journalctl -x |
Adds explanatory help text and context to log entries where available, useful for less-experienced admins interpreting cryptic messages. |
journalctl -a |
Shows all fields, even ones with unprintable/binary data (in escaped form) - useful for deep forensic inspection. |
journalctl -n 50 |
Limits output to the last 50 entries, a quick way to get a manageable snapshot without flooding the terminal. |
journalctl --no-pager |
Disables the interactive pager, printing straight to stdout - essential when piping journalctl output into other tools or scripts. |
Security and Integrity Checks
| Command / Option | What it accomplishes |
|---|---|
journalctl --verify |
Checks the cryptographic integrity of the journal files (when Forward Secure Sealing is enabled), helping detect tampering - an important tool for security-conscious administrators. |
journalctl -u sshd --since "-24 hours" -g "Accepted" |
A practical audit query: lists successful SSH logins in the last 24 hours, useful for reviewing legitimate access alongside failed attempts. |
journalctl _COMM=sudo |
Filters logs generated specifically by the sudo binary, useful for auditing privilege escalation activity across the system. |
journalctl -u fail2ban |
Reviews fail2ban’s own logs directly through journald, letting admins confirm bans, unbans, and detected abuse patterns in one place. |
Closing Notes
For administrators managing public-facing servers, journald’s combination of structured querying, boot-aware filtering, and tight systemd integration makes it a far more efficient forensic and monitoring tool than legacy flat-file logs alone. Pairing targeted journalctl queries - by unit, time window, priority, and pattern - with a retention policy via --vacuum-time or --vacuum-size keeps logs both useful for incident response and manageable in terms of disk usage.