Terminal.Drill Get the app
ch06/l01

Journal as scoped evidence

Filter logs by unit, boot, priority, and time window.

journalctl -u 25 min read, 30 min lab operator

`journalctl` is useful when scoped. Unit filters, boot filters, priority filters, and time windows turn a wall of logs into evidence. Always report the scope you used.

In the field

A service failed after the last reboot and you need logs from that boot only.

Worked command

$ journalctl -u nginx.service -b --no-pager$ journalctl -u nginx.service -S '1 hour ago' -p warning$ journalctl -xeu nginx.service
Anti-pattern

Do not paste unfiltered journal output and call it an investigation.

Safer pattern

State unit, boot/time window, and priority when reporting logs.

Knowledge check

You run `journalctl -u nginx.service -b`. What exactly does the `-b` restrict the output to?

  • A Only log lines from the current boot
  • B Only lines from the nginx binary, not its children
  • C Only the most recent log line (the bottom)
  • D Only buffered logs not yet written to disk
Show the answer

Correct: A. Only log lines from the current boot

Why

`-b` scopes to the current boot (use `-b -1` for the previous one); it is a time/session filter, not a process or buffer filter. The 'bottom line' guess confuses it with `-e`/`-n`, which control paging and line count.

Practice checklist

  1. Use a lab unit or sample output.
  2. Collect unit-scoped logs.
  3. Repeat with a time window.

Deliverable evidence

  • A log excerpt with unit and time scope stated.
Teaching diagramch06 · mental model
Four separate questions, four separate checks Active? systemctl status Enabled? is-enabled Logs? journalctl -u -b Unit file? systemctl cat runtime now at boot scoped evidence on disk edit unit file systemd still sees old copy daemon-reload, then restart

shows: Active, enabled, logs, and unit-file are four independent questions, and that a unit edit needs daemon-reload before systemd acts on it.

does not prove: It shows which checks to run, not their results: a green "active" box is a snapshot, not proof the service is healthy or will survive the next reboot.

Memorize this

Commit these to memory, then drill them until recall is automatic.

journalctl -u-b-S-p-xeu

Reference

journalctl -ujournalctl -b
Recall practice · Scenario -> next check

cue A service failed after the last reboot; show only this boot's logs for it

show recall target

journalctl -u <unit> -b

See this drill type Practice recall in the app