systemd sockets, paths, and activation

systemd can start services on demand rather than running them continuously. Three activation mechanisms:

• Socket activation: systemd holds a listening socket; the service starts when the first connection arrives.
• Path activation: systemd watches a file path; the service starts when the path appears or changes.
• Timer activation: covered separately (the previous lesson).

Socket activation

# /etc/systemd/system/sshd.socket
[Unit]
Description=OpenBSD Secure Shell server socket

[Socket]
ListenStream=0.0.0.0:22
Accept=false

[Install]
WantedBy=sockets.target

When this socket unit is enabled, systemd listens on port 22. The first incoming connection activates sshd.service (same name as the socket, with .service suffix). Subsequent connections go to the running service.

$ systemctl cat sshd.socket

# /usr/lib/systemd/system/sshd.socket
[Unit]
Description=OpenBSD Secure Shell server socket
Before=sshd.service
Conflicts=sshd.service

[Socket]
ListenStream=0.0.0.0:22
Accept=false
KeepAlive=true

[Install]
WantedBy=sockets.target

Path activation

# /etc/systemd/system/upload-watcher.path
[Unit]
Description=Watch for uploads in /srv/uploads/

[Path]
# DirectoryNotEmpty=, not PathExists= - see the callout below
DirectoryNotEmpty=/srv/uploads/incoming
Unit=upload-processor.service

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/upload-processor.service
[Unit]
Description=Process uploaded files

[Service]
Type=oneshot
ExecStart=/usr/local/bin/process-uploads.sh

With DirectoryNotEmpty=, the processor runs when files arrive, consumes them, and exits — and systemd waits for the next arrival because the directory is empty again.

$ ls -l /etc/systemd/system/*.path 2>/dev/null; systemctl list-unit-files --type=path

-rw-r--r-- 1 root root 230 Aug  9 11:11 /etc/systemd/system/upload-watcher.path
4 unit files listed.

Auto-restart and dependencies

Socket activation changes what Restart= is for, and it is easy to overstate what its absence costs.

Without Restart=, a socket-activated service that crashes is not dead to the world: the socket unit still holds the listening socket, so the next connection activates a fresh instance. Connections already in flight when it died are lost — that is the real cost — but the port keeps accepting.

Restart=on-failure is still worth setting, for a different reason: it brings the service back immediately rather than waiting for a client to notice, which matters when the service holds state or takes a long time to start.

The failure that does produce “connection refused” is the socket unit itself stopping — usually because the service hit StartLimitBurst and systemd stopped the socket to break the loop:

$ systemctl status myapp.socket
   Active: failed (Result: start-limit-hit)

That is the state to alert on, and systemctl reset-failed myapp.socket myapp.service is what clears it once the underlying fault is fixed.

[Service]
ExecStart=/usr/bin/myapp
Restart=on-failure
RestartSec=5

When to use activation vs always-on

Knowledge check