Terminal.Drill Get the app
ch06/l03

Unit files, timers, and daemon reload

Know where systemd configuration lives and when systemd must reread it.

systemctl list-timers 25 min read, 35 min lab operator

Unit files define services, timers, mounts, sockets, and more. Editing a unit file requires `systemctl daemon-reload` before systemd sees the change. Timers are scheduled unit triggers, not cron clones.

In the field

A timer should run a cleanup service every hour, but the new unit edit is ignored.

Worked command

$ systemctl cat backup.timer$ systemctl list-timers --all$ sudo systemctl daemon-reload$ systemd-analyze verify ./backup.service
Anti-pattern

Do not edit units and restart blindly without daemon-reload and validation.

Safer pattern

Validate unit shape, reload systemd, then restart or enable the unit.

Knowledge check

You edited a unit file and ran `systemctl restart` on it, but your change is ignored. Why?

  • A systemd still holds the old unit; you must daemon-reload first
  • B restart only reloads config for timers, not services
  • C The edit needs a full reboot before systemd can read it
  • D restart cleared the change; you should have used reload
Show the answer

Correct: A. systemd still holds the old unit; you must daemon-reload first

Why

systemd caches unit definitions in memory; `systemctl daemon-reload` makes it reread the file, then restart applies it. A reboot would also work but is overkill, and `reload` asks the running service to reload its own config, not systemd to reread the unit.

Practice checklist

  1. Read `systemctl cat` for an existing unit.
  2. List timers.
  3. Use sample unit text with `systemd-analyze verify` if available.

Deliverable evidence

  • Unit path, timer state, and reload/verify note.
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 catdaemon-reloadlist-timerssystemd-analyze verify

Reference

systemctl statussystemd-analyze blame
Recall practice · Scenario -> next check

cue Edited a unit file; make systemd reread it before restarting

show recall target

sudo systemctl daemon-reload

See this drill type Practice recall in the app