The journalctl command in Linux
journalctl reads the systemd journal, the structured log store where modern Linux keeps everything: kernel messages, service output, boot records. Its power is filtering — by unit, time range, priority, boot — turning "somewhere in the logs" into a two-flag query. Paired with systemctl, it is the modern debugging loop.
How journalctl works
The journal is not a text file: journald stores structured, indexed binary records. Each entry carries your message plus trusted metadata added by journald itself — _PID, _UID, _SYSTEMD_UNIT, timestamps — which a program cannot forge about itself. Filters like -u or -p are index lookups over those fields, not text scans, which is why they stay fast at gigabyte scale.
That structure explains the ergonomics: -o json exposes every field for tooling; correlation across services just works because everything shares one timeline; and completeness beats classic syslog because journald also captures each unit's raw stdout/stderr. The single operational trap: without /var/log/journal, the journal lives in RAM and each boot starts blank — persistent storage is one mkdir away and belongs in every server checklist.
Syntax
journalctl [OPTIONS]Common options
| Option | What it does |
|---|---|
-u UNIT | Only one service's logs. |
-f | Follow live, like tail -f. |
--since / --until | Time windows: "10 min ago", "2026-08-04 09:00", yesterday. |
-p err | Only this priority and worse (emerg…debug). |
-b / -b -1 | This boot / previous boot. |
-n 50 | Last 50 lines. |
-o json | Structured output for tooling. |
How to use journalctl: examples
$ journalctl -u nginx -fFollow one service live — the modern tail -f of its log.
$ journalctl -u myapp --since "15 min ago"What happened around the alert.
$ journalctl -p err -bEvery error since boot, all sources — the machine-wide health sweep.
$ journalctl -b -1 -eThe end of the PREVIOUS boot's logs: what was happening right before that unexpected reboot.
$ journalctl --disk-usageHow much space the journal itself consumes.
Real-world use cases for journalctl
The incident time-box
Alert at 09:41: journalctl --since 09:35 --until 09:45 shows EVERYTHING the machine did in that window — all services interleaved on one timeline. Cross-service causality (db hiccup → app errors → health-check restarts) that separate log files hide by construction.
Explaining the mystery reboot
The server restarted overnight: journalctl -b -1 -e shows the final moments of the previous boot — OOM kills, kernel panics, or a polite shutdown someone forgot to mention. The flight recorder for "what happened before the crash".
Pro tips and common mistakes
- Make the journal persistent on every server: mkdir /var/log/journal. Without it, reboots erase your history exactly when you need it.
- -u service -f is your live tail; add --since "5 min ago" when opening an investigation.
- -p err -b is the machine-wide error sweep — run it after every maintenance before declaring victory.
Frequently asked questions about journalctl
Why is journalctl empty for my service?
Either the unit name is wrong (systemctl list-units | grep name) or the service writes to its own files instead of stdout — check its config for log paths.
Do journal logs survive reboot?
Only with persistent storage: /var/log/journal must exist (mkdir it and restart systemd-journald). Otherwise the journal lives in RAM and each boot starts blank.
How do I jump to the end?
journalctl -e opens the pager at the tail; inside the pager, G jumps to the end, / searches.
Related commands
Find lines matching a pattern in files or piped input — the workhorse of text search.
head & tailPrint the first or last lines of a file — including live log following with tail -f.
systemctlStart, stop, enable and inspect services — the control panel of modern Linux.