Service Management with systemctl

systemctl verbs, unit file Wants/Requires/After, target units, enable vs start, and daemon-reload.

Overview

systemctl is the primary interface to systemd — the init system, service manager, and system state machine on every major Linux distribution. Understanding systemctl deeply means understanding how services start, how dependencies are resolved, how to diagnose failures, and how the system boots.

Unit Types

systemd manages units — not just services. Unit types include: .service (daemons), .socket (socket activation), .target (dependency groups), .timer (cron replacement), .mount (filesystem mounts), .device (udev devices), .path (filesystem watch).

Essential systemctl Verbs

start — Start the unit now
stop — Stop the unit now
restart — Stop then start
reload — Send SIGHUP (reload config without restart)
status — Show unit state, last log lines, PID
enable — Create symlink to start at boot
disable — Remove boot symlink
mask — Symlink to /dev/null — prevents any start
unmask — Remove the /dev/null symlink
daemon-reload — Re-read all unit files from disk

Dependency Directives

Unit file [Unit] section directives control ordering and dependencies:

After= — ordering only. This unit starts after the listed units are active. Does not require them to be present.
Requires= — hard dependency. If the required unit fails to start or stops, this unit is also stopped.
Wants= — soft dependency. Systemd will try to start the wanted unit, but this unit is not stopped if the wanted unit fails.
Before= — this unit must start before the listed units.
BindsTo= — like Requires but tighter: if the bound unit stops for any reason, this unit stops immediately.

Target Units

Targets are grouping units with no executable payload. Key targets:

multi-user.target — multi-user text mode (server default)
graphical.target — GUI mode (extends multi-user.target)
network.target — network is up
rescue.target — minimal single-user recovery

Key concepts

start vs enable: start — runs the unit now. enable — creates a symlink so the unit starts at next boot. A service can be running but not enabled (starts manually) or enabled but stopped (will start at boot).
restart vs reload: restart — stops and starts the process (brief downtime, new PID). reload — sends SIGHUP; the process re-reads its config with no downtime. Only works if the service supports SIGHUP reload.
mask: Creates a symlink /etc/systemd/system/servicename.service -> /dev/null. The unit cannot be started by any means — not manually, not as a dependency. Stronger than disable.
daemon-reload: Required after any unit file change. Instructs systemd to re-read all unit files from disk. Without it, systemd runs the old unit definition even if the file has changed.
Wants= vs Requires=: Wants= is a soft dependency — the wanted unit is started if possible, but failure doesn't stop this unit. Requires= is hard — if the required unit fails, this unit is stopped too.
systemctl isolate: Switches the system to a specific target, stopping all units not wanted by that target. systemctl isolate rescue.target puts the system in rescue mode. Use with care — stops services.

When to use it

Reloading nginx config without dropping connections — systemctl reload nginx (SIGHUP, no downtime)
Preventing a service from ever starting — systemctl mask servicename
Diagnosing a service that fails to start — systemctl status + journalctl -u + systemd-analyze verify
Understanding boot order — systemctl list-dependencies multi-user.target
After editing a unit file — systemctl daemon-reload is required before the change takes effect

Interview questions

What is the difference between systemctl restart and systemctl reload? When should you use each?
Walk through writing a systemd unit file for a custom application with proper dependencies.
What does systemctl mask do, and when would you use it instead of disable?