The Journal (journalctl)

journalctl

Traditional Linux logging wrote plain text lines to files under /var/log. systemd introduced an alternative: the journal, a structured, indexed binary log that every systemd-managed service's output is captured into automatically - no separate logging configuration required per service. You query it with the journalctl command rather than grep-ing text files.

Because every entry is structured (tagged with which unit produced it, which boot it happened in, its severity level), journalctl can slice logs along dimensions plain-text log files make painful - like "show me only this one service's output from the boot before last" (journalctl -u nginx -b -1), which would otherwise mean manually correlating timestamps across a rotated log file.

By default the journal lives in RAM (/run/log/journal) and is wiped on every reboot - useful for keeping disk usage bounded, but it means you lose history across restarts. Making it persistent (surviving reboots) is a one-time setup: create the directory /var/log/journal and restart the journal service (systemctl restart systemd-journald) so it switches to writing there instead.

$ journalctl -u sshd --since today -p warning

That command reads as: "show me sshd's log entries from today, at warning severity or worse" - combining a unit filter, a time filter, and a severity filter in one line.

Tip: The severity levels behind -p come from the standard syslog scale, worst to least severe: 0 emerg, 1 alert, 2 crit, 3 err, 4 warning, 5 notice, 6 info, 7 debug. -p shows that level and everything more severe (lower-numbered) - so -p err includes err, crit, alert, and emerg, but not warning or below. This is the opposite of what the numbers might intuitively suggest, so it's worth remembering explicitly.