Instiq
Chapter 1 · System startup and the Linux kernel·v1.0.0·Updated 7/7/2026·~12 min

What's changed: Initial version (topic 2.01, subtopics 2.01.1–2.01.5)

1.2Customizing System Startup

Key points

Go deeper on operating systemd services: the three-layer config hierarchy (/usr/lib/systemd/, /etc/systemd/, /run/systemd/), unit operations with systemctl (status, list-units, start, stop, enable, disable, mask, unmask), diffing config layers with systemd-delta, and when to use rescue vs emergency mode.

"Why won't this service start?" "I changed the config but it did not take effect"—answering these requires understanding where systemd reads its config from and what overrides what. Exam 201 focuses heavily on this hierarchy and practical systemctl commands.

1.2.1The systemd config file hierarchy

  • /usr/lib/systemd/ holds the default unit files shipped by packages. Package updates overwrite this, so never edit here directly.
  • /etc/systemd/ is where administrators put customizations. Override a default by placing a same-named file or a drop-in (a .d/ directory) here.
  • /run/systemd/ holds runtime (volatile) configuration—transient units and state that disappear on reboot.
  • Precedence: /etc/ overrides /usr/lib/, and /run/ overrides both transiently. systemd-delta lists which files are overridden where across the three layers.

1.2.2Unit operations with systemctl and failure modes

  • Inspection: systemctl status <unit> (detailed state) and systemctl list-units (currently loaded units, narrow with --type=service, etc.).
  • Runtime control: start/stop (act right now) vs enable/disable (toggle auto-start on future boots by creating/removing symlinks).
  • Lockout: mask makes a unit completely unstartable (symlinks it to /dev/null, so even start fails) and unmask reverses it. Stronger than disable—it also blocks incidental starts pulled in by dependencies.
  • rescue mode (rescue.target) is minimal-service, single-user maintenance with root login. emergency mode (emergency.target) is the last resort: it mounts the root filesystem read-only and does not even start what rescue does.
Exam point

The most-tested distinction: right now = start/stop, from next boot = enable/disable, fully locked = mask. "Prevent a service from starting even via a dependency pull" points to mask, not disable. The rescue vs emergency contrast (root FS mounted read-write vs read-only) is another exam staple.

Trace the practical config-change flow. Avoid editing vendor units directly (e.g., /usr/lib/systemd/system/sshd.service); instead hand-craft a drop-in such as /etc/systemd/system/sshd.service.d/override.conf on the /etc/ side. This way the /etc/ layer overrides the /usr/lib/ default and survives package upgrades. When unsure which file wins where, run systemd-delta to see the three-layer overlay. After a change, apply it with systemctl stop sshd followed by systemctl start sshd. To permanently disable a service, use systemctl disable <unit>—but if you are worried it could still start incidentally via another unit's dependency, go further with systemctl mask <unit>. If the system enters a boot loop, append systemd.unit=rescue.target to the GRUB2 kernel line for minimal-config maintenance; if it is too broken even for that, use systemd.unit=emergency.target to get a shell with the root FS still mounted read-only and inspect/fix configuration files.

Layer / commandPurposeKey point
/usr/lib/systemd/Package defaultsNever edit directly
/etc/systemd/Admin customizationOverrides defaults; survives upgrades
systemctl enable/disableAuto-start from next bootDoes not act immediately
systemctl maskFully lock out startingBlocks incidental dependency starts too
Warning

Trap: "systemctl disable fully locks a service so even start fails" is wrong—once re-enabled, start works normally; mask is the one that blocks even start. Also wrong: "emergency.target starts more services than rescue.target"—emergency is even more minimal (read-only root FS, and it skips some services that rescue does start).

Diagram of the /usr/lib, /etc, /run precedence layers and the start/enable/mask distinction.
Override precedence and lockout strength

1.2.3Section summary

  • Config layers = /usr/lib (default) < /etc (admin) < /run (runtime); check overlaps with systemd-delta
  • start/stop = now / enable/disable = from next boot / mask = fully locked; emergency is even more minimal than rescue

Sign in to track progress — Log in.

Quick check

(just a quick review)

Q1. A service keeps starting unintentionally, pulled in by another unit's dependency. What is the most reliable way to prevent it from ever starting?

Q2. You want to safely add custom settings without modifying the vendor-provided /usr/lib/systemd/system/sshd.service. What is the appropriate approach?

Q3. Which statement correctly describes the difference between rescue.target and emergency.target?

Check your understandingPractice questions for Chapter 1: System startup and the Linux kernel