Terminal.Drill Get the app
ch06 · operator · 95-130 min

logs and systemd services

Read service state, journal evidence, unit files, timers, and daemon reload boundaries.

You can produce a service troubleshooting packet that another operator can trust.

systemdjournalctllogsservicestimers
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.

Lessons in this chapter

  1. ch06/l01 Journal as scoped evidence journalctl -u Filter logs by unit, boot, priority, and time window.
  2. ch06/l02 Service lifecycle and enablement systemctl status Separate active state from boot-time enablement.
  3. ch06/l03 Unit files, timers, and daemon reload systemctl list-timers Know where systemd configuration lives and when systemd must reread it.
capstone

service troubleshooting packet

Build a packet for a failed or sample service: status, enablement, logs, unit path, suspected failure class, and next action.

Deliverable

A concise packet another operator could use without rerunning every command.

Success criteria

  • Active and enabled are separate.
  • Journal scope is stated.
  • Unit edits mention daemon-reload.
Terminal Drill companion

Systemd

After your packet separates service state, logs, enablement, and next action.

Train after the lesson

Service state -> actionOutput -> explanationFailure -> diagnostic