Terminal.Drill Get the app
ch06/l02

Service lifecycle and enablement

Separate active state from boot-time enablement.

systemctl status 25 min read, 30 min lab operator

`systemctl start` changes current runtime state. `enable` changes whether a unit starts at boot. `status` is a snapshot; pair it with journal output and unit file inspection when troubleshooting.

In the field

A service is running now but does not survive reboot.

Worked command

$ systemctl status ssh.service$ systemctl is-enabled ssh.service$ systemctl list-unit-files 'ssh*'$ sudo systemctl enable --now ssh.service
Anti-pattern

Do not assume active means enabled or enabled means healthy.

Safer pattern

Check active, enabled, logs, and unit file path separately.

Knowledge check

`systemctl status ssh` shows active (running) but the service is gone after every reboot. What does this tell you?

  • A It is active now but not enabled, so it won't start at boot
  • B It is enabled but unhealthy and crashing on boot
  • C The unit file is missing and must be reinstalled
  • D status is wrong; only journalctl can show real state
Show the answer

Correct: A. It is active now but not enabled, so it won't start at boot

Why

Active is runtime state; enable controls boot-time start. Run `systemctl is-enabled ssh` and `enable --now` to persist it. The 'crashing on boot' guess assumes it tries to start at boot at all, but a disabled unit is never invoked.

Practice checklist

  1. Inspect a harmless service.
  2. Record active and enabled state.
  3. Find recent unit logs.

Deliverable evidence

  • A service state table: active, enabled, recent logs, unit path.
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.

systemctl statusis-enabledenable --nowrestartreload

Reference

systemctl statusjournalctl -u
Recall practice · Service state -> action

cue Service runs now but does not survive reboot: make it start at boot and right now

show recall target

sudo systemctl enable --now <unit>

See this drill type Practice recall in the app