Logs with journalctl.
systemd collects every service's output into one structured journal — then journalctl lets you slice it by unit, time, and priority. Learn the handful of filters that turn a wall of logs into the three lines that actually matter.
Logs with journalctl animated tutorial. The systemd journal, filtering by unit (-u), priority (-p), and time (--since/--until), following live logs (-f), listing boots (-b), and configuring a persistent journal. RHCSA EX200 ready.systemd funnels every service's output into one structured, queryable journal. Watch each filter narrow a wall of logs down to the lines that matter.
- ·Comfortable starting/checking services with systemctl
- ·Helpful: the systemd targets lesson (units, services)
- ·Know roughly what stdout/stderr are
Filter the journal by unit, priority, and time; follow logs live; inspect previous boots; and make the journal persistent.
pace: 9 minutes
The journal — one structured log for everything
On systemd systems, every service's stdout/stderr and every kernel message lands in ONE place: the journal. It's binary and indexed (not plain text), so you can query it by field — which unit, which priority, which time — instead of grepping scattered files. `journalctl` with no arguments prints all of it, oldest first.
$journalctl$journalctl -e$journalctl -n 20The journal is structured, not plain text. Every entry carries fields — unit, priority, PID, timestamp, and more — so journalctl filters are exact and composable. The real skill isn't reading logs, it's stacking filters: journalctl -u nginx -p err --since "1 hour ago" turns thousands of lines into the three that explain the outage.
$journalctl -u UNIT$journalctl -p err$journalctl --since "09:18"$journalctl --until "10:00"$journalctl -f$journalctl -e$journalctl -n 50$journalctl -r$journalctl -b / -b -1$journalctl --list-boots$journalctl -k$journalctl _PID=1234$journalctl -o json-pretty$journalctl --disk-usage$journalctl --vacuum-time=2weeks$/etc/systemd/journald.confYou want to see only the logs for the nginx service. Which command?
`journalctl -p err` is running. A 'warning' message appears. Is it shown?
A server crashed and rebooted. You want the logs from BEFORE the reboot. What do you run — and what might prevent it from working?
You want to watch a service's logs live while you reproduce a bug. Best command?
These aren't graded — they're just for active recall, which is what actually makes the lesson stick.
systemd targets & units
Every line in the journal comes from a unit. Understand how systemd starts and supervises those services, and the `-u` filter suddenly makes total sense.
Read this lesson as text6 chapters · quiz answers
01The journal — one structured log for everything
On systemd systems, every service's stdout/stderr and every kernel message lands in ONE place: the journal. It's binary and indexed (not plain text), so you can query it by field — which unit, which priority, which time — instead of grepping scattered files.
journalctlwith no arguments prints all of it, oldest first.$ journalctl— everything, oldest → newest$ journalctl -e— jump to the end (newest)$ journalctl -n 20— last 20 lines only
02Filter by unit — -u
Almost every investigation starts here: show only one service's logs.
journalctl -u nginx(or nginx.service) hides everything else. Combine units by repeating -u. This is the single most useful journalctl flag — pair it withsystemctl status nginx, which shows the last few journal lines for the unit inline.$ journalctl -u nginx— just nginx$ journalctl -u nginx -u sshd— two units$ systemctl status nginx— status + last log lines
03Filter by priority — -p
Logs have syslog priorities from 0 (emerg) to 7 (debug). LOWER is more severe.
journalctl -p errshows err and everything more severe (crit, alert, emerg) — it hides info, notice, debug noise. Great for 'just show me the problems'. The warning at 09:18 is NOT shown because warning (4) is less severe than err (3).$ journalctl -p err— err and worse (≤3)$ journalctl -p warning— warning and worse (≤4)$ journalctl -u nginx -p err— combine: nginx errors only
04Filter by time — --since / --until
Narrow to a window.
--sinceand--untilaccept absolute times ('2026-05-27 09:18'), clock times ('09:18'), or human phrases ('1 hour ago', 'yesterday'). Here--since 09:18drops everything before 09:18 — exactly what you want when you know roughly when the incident started.$ journalctl --since "09:18"— from 09:18 onward$ journalctl --since "1 hour ago"— relative time$ journalctl --since today --until "12:00"— a bounded window
05Follow live — -f
journalctl -ftails the journal live, printing new entries as they arrive — the journal equivalent oftail -f. Combine with -u to watch one service while you reproduce a bug:journalctl -u nginx -f. Ctrl-C to stop. This is what you leave running in one terminal while you poke the service in another.$ journalctl -f— follow everything live$ journalctl -u nginx -f— follow one service
06Boots and persistence — -b
journalctl -bshows only the current boot;-b -1the previous boot — invaluable for diagnosing a crash that required a reboot.journalctl --list-bootslists them. By default many systems keep the journal in RAM (lost on reboot). To make it survive, create /var/log/journal (or set Storage=persistent in journald.conf) — then -b -1 actually has something to show.$ journalctl -b— current boot only$ journalctl -b -1— previous boot (crash diag)$ journalctl --list-boots— all recorded boots$ mkdir -p /var/log/journal— make the journal persistent$ journalctl --disk-usage— how big is it?
Quiz — answers
- You want to see only the logs for the nginx service. Which command?
- →journalctl -u nginx
-ufilters by systemd unit and is the right tool — it matches the unit field exactly, not just any line containing 'nginx'.grep nginxwould also catch unrelated lines that happen to mention nginx, and miss structured fields. journalctl -p erris running. A 'warning' message appears. Is it shown?- →No — priorities go 0 (emerg) … 7 (debug), LOWER is more severe. err is 3, warning is 4, so -p err shows only ≤3 (err and worse).Lower number = more severe.
-p err(3) includes err, crit, alert, emerg — but NOT warning (4), notice (5), info (6), or debug (7). It's a 'show me at least this bad' filter. - A server crashed and rebooted. You want the logs from BEFORE the reboot. What do you run — and what might prevent it from working?
- →journalctl -b -1 — but if the journal isn't persistent (no /var/log/journal), the previous boot's logs were lost on reboot.
-b -1selects the previous boot. But if journald is volatile (RAM-only, the default on some systems), those logs vanished at reboot. Create /var/log/journal (or set Storage=persistent) ahead of time so post-crash forensics is possible. - You want to watch a service's logs live while you reproduce a bug. Best command?
- →journalctl -u myservice -f
-ffollows the journal live (like tail -f), and-u myservicescopes it to one unit. Leave it running in one terminal and trigger the bug in another to see exactly what the service logs in real time.
keep going — these pair well with what you just learned.
SELinux contexts
Why Apache can't read your file. Watch the policy engine decide — and learn the workflow for fixing denials. RHCSA-ready.
Linux boot process
From power button to login prompt. Every stage in the chain — UEFI, GRUB, kernel, initramfs, systemd — with the rescue moves that save you. RHCSA-ready.
LVM stacking
Layer-by-layer build of an LVM stack: disks → PVs → VG → LVs → filesystem. Then extend live and snapshot. RHCSA-ready.