Skip to content
AITroveRead. Build. Understand.
Make this comfortable

systemd socket activation: preserve the listener without hiding service failure

Last updated: 5 Oct 20267 min read
tutorial
AdvancedBy AITrove Editorial

With systemd socket activation, the service manager opens a listening socket and passes its file descriptor to a compatible daemon. A socket unit with Accept=no normally activates one matching service that handles all accepted traffic; the daemon must use the inherited descriptor rather than trying to bind the same address again. A healthy socket unit does not prove the application is healthy: requests can queue or fail while the service crashes, starts slowly, or rejects work. Socket activation is an endpoint-ownership mechanism, not an application readiness check or a substitute for a load balancer's user-path probe.

Operational decision

A local image processor listens on a Unix socket. The operator enables its socket unit, leaves the service stopped, and sends one synthetic request. The service starts, accepts the inherited descriptor, and records the request ID. Then they kill the service during a burst of 47 requests and observe connection outcomes, queueing, restart delay, and whether any request effect ran twice. The service must not unlink a socket path it did not create. If the app cannot consume passed descriptors, the team keeps ordinary service-owned binding instead of turning on a socket unit that merely holds a port and masks the incompatibility.

Output
Socket: image-worker.socket
Accept=no: one image-worker.service handles connections
First request: activates service through inherited descriptor
Fault: kill service during 47 synthetic requests
Verify: connection outcomes, effect IDs, restart time, user-path probe

Cost and verification

Keeping a listener open across service restarts can reduce bind races, but it can also let the socket backlog grow while no worker can answer. Backlog capacity and client timeouts therefore need measurement under a crash, not only during clean startup. An idle socket may show active even when its service is rate-limited and unavailable. Observe both units plus a real request, and alert on a service that repeatedly fails after activation. A long-running effect still needs an idempotency key because a client may retry after losing the response.

Common Mistakes

  • Do not enable a socket unit for a daemon that cannot use inherited descriptors.
  • Do not treat an active socket as application readiness.
  • Do not remove a socket path owned by the service manager from the daemon.

Connected lessons

Practice and check

devops
systemd
linux-services
Storage details