Unit Files

A unit file is the declarative config that tells systemd how to manage one resource. The resource can be a long-running service, a listening socket, a scheduled timer, a filesystem mount, a watched path, or a target that groups other units. The format is INI-style: sections in square brackets like [Unit] and [Service], each holding Key=Value directives. You describe the desired state and the dependencies; systemd decides the order and does the work.

Where the file lives decides whether your edit survives. Vendor units ship under /lib/systemd/system (a symlink to /usr/lib/systemd/system on Ubuntu 24.04 and Debian 12); your overrides belong under /etc/systemd/system. Edit the vendor copy directly and the next apt upgrade of that package silently replaces your changes. systemd merges the two trees at load time, so the layer you write into determines whether your configuration is durable or disposable.

Unit File Anatomy

A service unit has three sections, each with a distinct job. [Unit] carries metadata and relationships: Description, ordering with After, and dependencies with Wants or Requires. [Service] defines the process itself: ExecStart for the command, ExecReload for a reload signal, Restart and RestartSec for failure handling, and User and Group to drop privileges. [Install] holds only what systemctl enable acts on — usually WantedBy, which names the target that should pull this unit in at boot.

A complete unit for a simple web daemon looks like this:

# /etc/systemd/system/widget-api.service
[Unit]
Description=Widget API server
After=network-online.target postgresql.service
Wants=network-online.target

[Service]
Type=notify
User=widget
Group=widget
ExecStart=/usr/local/bin/widget-api --port 8080
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

The Override Hierarchy

systemd reads units from a search path with a fixed precedence. /etc/systemd/system wins over /run/systemd/system, which wins over /usr/lib/systemd/system. A file with the same name in a higher-precedence directory replaces the lower one wholesale. That is the heavy hammer: it works, but you now own the entire unit and lose any improvements the package ships later.

The precise tool is a drop-in. systemctl edit widget-api opens an empty override.conf under /etc/systemd/system/widget-api.service.d/, and systemd merges those directives on top of the vendor file. You override only the keys you care about — bump MemoryMax, change Restart — while the rest of the vendor unit stays live and keeps tracking upstream. Use systemctl cat widget-api to print the effective merged unit, vendor file plus every drop-in, in load order.

systemd does not watch unit files on disk. After any change — a new file, an edited drop-in, a deletion — you must run systemctl daemon-reload so the manager re-reads its configuration. Until you do, systemctl keeps acting on the version it parsed at last load. systemctl edit runs the reload for you; a manual edit with an editor does not.

Unit Types

The file extension picks the unit type, and each type has its own directive set. A .service manages a process; a .socket holds a listening socket that can start its service on first connection; a .timer replaces a cron entry with systemd's own scheduling. Targets are synchronization points, not processes — multi-user.target is the rough equivalent of the old SysV runlevel 3.

Extension	Manages	Common directives
.service	A process or daemon	ExecStart, Type, Restart
.socket	A listening socket for activation	ListenStream, Accept
.timer	Scheduled activation of a unit	OnCalendar, OnBootSec
.target	A grouping / sync point	Wants, Requires
.mount	A filesystem mount point	What, Where, Type
.path	A watched file or directory	PathExists, PathModified

Types compose by name. A widget-api.socket and a widget-api.service pair up automatically, so the socket can listen at boot and hand the connection to the service only when traffic arrives. A .timer activates the matching .service of the same stem unless you point it elsewhere with Unit=.

Dependencies and Ordering

Dependency and ordering are two separate axes, and conflating them is the most common unit-file error. Wants and Requires declare that another unit should also be running: Wants is a soft pull where failure of the dependency is tolerated, while Requires is hard — if the required unit fails to start, your unit is not started either. Requisite is stricter still: it refuses to start unless the other unit is already active, and never triggers it. BindsTo goes further than Requires by also stopping your unit if the bound unit later stops.

After and Before control only sequence, not whether a unit is pulled in. After=postgresql.service says "if postgresql is in this transaction, start it first," but it does not request postgresql at all. You almost always pair the two: Wants=network-online.target to request it and After=network-online.target to wait for it. Without an explicit ordering directive, systemd starts units in parallel.

Resource Limits and Sandboxing

Because every service runs inside its own cgroup, the [Service] section can cap what it consumes. MemoryMax=512M sets a hard ceiling the kernel enforces by killing the service if it exceeds it; CPUQuota=50% limits it to half of one core's time. These contain a runaway process before it starves the rest of the host, and they cost nothing when the service stays within budget.

The same section hardens the service against the rest of the system. ProtectSystem=strict mounts the entire filesystem read-only except the API trees /dev, /proc, and /sys; PrivateTmp=true gives the unit its own /tmp that no other process can see; NoNewPrivileges=true blocks setuid binaries from escalating privilege. The trade-off is real: tighten ProtectSystem too far and a daemon that writes to a state directory fails until you add a ReadWritePaths= exception, so verify each change against the service's actual filesystem needs.