Writing systemd unit files

Most production daemons ship their own unit files. When you need your own — for a custom application, a deployment hook, or a monitoring agent — you write a unit file. The format is INI-like with sections and directives.

A minimal service unit

[Unit]
Description=MyApp daemon
Documentation=https://wiki.example.com/myapp
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/opt/myapp/bin/myapp
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Place this in /etc/systemd/system/myapp.service, then:

sudo systemctl daemon-reload
sudo systemctl enable --now myapp
systemctl status myapp

$ systemctl cat myapp

# /etc/systemd/system/myapp.service
[Unit]
Description=MyApp daemon
...

The [Unit] section

To both order and depend, you need two directives: pair After=X with Wants=X or Requires=X.

The [Service] section

$ systemctl show myapp.service | grep -E '^(Type|ExecStart|Restart|User)'

Type=simple
ExecStart={ path=/opt/myapp/bin/myapp ; argv[]=/opt/myapp/bin/myapp }
Restart=on-failure
User=root

Restart=, start rate limits, and reset-failed

Restart= is only half of a restart policy. systemd also rate-limits how often a unit may start. Exceed the limit and the unit lands in a failed state with Result: start-limit-hit, and every subsequent systemctl start or systemctl restart is refused — including the one you issue after fixing the problem.

The limit is StartLimitBurst starts within StartLimitIntervalSec, defaulting to DefaultStartLimitBurst= / DefaultStartLimitIntervalSec= from the manager configuration — 5 starts in 10 seconds on a stock system. Both directives live in [Unit], which is a common authoring mistake:

[Unit]
Description=MyApp daemon
StartLimitIntervalSec=60
StartLimitBurst=3

[Service]
Restart=on-failure
RestartSec=5

Restart=always on a service that fails during start-up produces a crash loop that burns CPU and floods the journal until the rate limit trips. Prefer Restart=on-failure, always set RestartSec=, and size StartLimitBurst deliberately rather than inheriting the 5-in-10s default.

The operator half of the competency is the recovery:

systemctl status myapp
# Active: failed (Result: start-limit-hit)
# Job for myapp.service failed because the control process...

systemctl reset-failed myapp   # clears the failed state AND the rate-limit counter
systemctl start myapp

Resource controls

[Service] supports a wide range of resource directives that translate to cgroup settings:

$ systemctl show myapp.service | grep -E '^(CPUQuota|MemoryMax|IOWeight|TasksMax)'

CPUQuota=200%
MemoryMax=2G
MemoryHigh=1G
IOWeight=100
TasksMax=256

Security hardening directives

systemd supports a rich set of security directives that restrict what the service can do:

1. Place the unit file in /etc/systemd/system/.
2. Run systemctl daemon-reload after every edit.
3. Use systemd-analyze verify <unit> to catch syntax errors before activating.
4. Add hardening directives incrementally. Test after each
5. Use drop-ins for partial overrides — /etc/systemd/system/<unit>.d/override.conf is cleaner than rewriting the unit file
6. Document resource limits in the runbook. A reviewer should know why CPUQuota=200% was chosen

Knowledge check