Writing a Custom Service Unit

systemd1-2 showed the shape of a unit file without explaining any field in depth. This chapter is that depth — and the real service written here is the same one systemd1-11's own capstone actually deploys.

[Unit] Section In Depth

Description= is shown directly in systemctl status output — worth writing something genuinely useful, not a placeholder. Documentation= is optional, a URL or man page reference. After=/Requires= are previewed here; systemd1-4 covers them in full.

[Service] Section — Type=

The field that determines how systemd knows whether the service actually started successfully:

• Type=simple (the default) — the process started by ExecStart= is the main process; systemd considers the service started the moment it forks
• Type=forking — for older-style daemons that fork into the background and exit the original process; systemd needs PIDFile= to know which PID to actually track
• Type=oneshot — a command that runs once and exits, not a long-running daemon at all; commonly paired with RemainAfterExit=yes so systemctl status still reports "active" after it finishes — directly relevant to systemd1-7's own timer-paired service units
• Type=notify — the service itself signals "I'm actually ready now" back to systemd; the most precise option, but requires the application to support it

ExecStart=, ExecStop=, ExecReload=

ExecStart= is required — the actual command that is the service. It must use an absolute path, a genuinely common beginner mistake: no shell PATH lookup happens here the way it would in an interactive terminal. ExecStop= is optional — for Type=simple, systemd can usually just send SIGTERM to stop the process cleanly; only write one when a service needs a genuinely custom shutdown command. ExecReload= runs on systemctl reload NAME — a real, common third action beyond just start/stop, typically telling a running process to re-read its config without a full restart.

Restart= — Automatic Recovery

Restart=on-failure (or always, or the default no) tells systemd to automatically restart the service if it exits unexpectedly. RestartSec= adds a delay before the restart attempt, avoiding a tight crash-loop hammering the system. A genuinely valuable capability with no clean System V init equivalent — one more concrete payoff of systemd1-1's own "why systemd replaced init" material.

[Install] Section — WantedBy=

WantedBy=multi-user.target is what systemctl enable actually acts on — the line determining which target's own .wants/ directory receives the new symlink. Different WantedBy= values matter for different kinds of services, previewed here and covered fully in systemd1-5's own targets chapter.

A Full Worked Example — Toward the Capstone

Every field here is explained above — this is the actual shape systemd1-11's own capstone deploys for real. User=myapp is worth a light callback of its own: running a service as a dedicated, non-root user rather than root by default is a genuinely security-relevant habit, the same least-privilege instinct owasp1/bc1 already established elsewhere on this site.

Applying a New or Changed Unit File

systemctl daemon-reload is required after creating or editing any unit file — it tells systemd to re-read unit files from disk. Forgetting it is a real, common "why isn't my change taking effect" gotcha.

Hands-On Exercises