You are asked to make in-house Linux services restart without refusing connections, and someone proposes putting every service behind a systemd socket unit. How would you decide where socket activation is the right tool and where it is not?

## Separate the two things it actually buys Socket activation delivers two distinct benefits, and conflating them is what leads to blanket adoption proposals. **On-demand start.** The service costs nothing until someone connects. This is real value on a host with many rarely used services, on developer machines, and for local `AF_UNIX` endpoints such as an agent or a management interface that sees traffic once a day. **Restart continuity on one host.** The listening socket lives in PID 1, so a service restart converts "connection refused" into "connection queued". This is real value for in-place restarts: config changes, package upgrades, crash recovery. Neither has anything to do with rolling out a new version safely, and that is usually what someone means when they say "zero-downtime". ## The prerequisite that decides most cases The daemon must cooperate. It has to look for the passed descriptors and use them instead of binding, and nothing in systemd can make an unaware program do that. So "put every service behind a socket unit" is, in practice, a proposal to modify every service. For daemons that already support it the change is a unit file; for the rest it is a code change, a review, a release, and a regression risk in the startup path — the single most safety-critical path a service has. My first action would therefore be an inventory: which services already support activation, which could support it with a small patch, and which are third-party binaries that never will. The answer to that shapes the whole plan. ## Where it is clearly worth it - Local Unix-socket services where there is no load balancer and never will be. The socket unit also gives you a clean place to set ownership and mode. - Services with a meaningful idle footprint that are used occasionally. - Hosts where the boot ordering graph is painful, since a socket that exists from early boot removes the need for clients to be ordered after servers. - Anything already shipping with a socket unit from the distribution, where the cost is zero. ## Where it is the wrong tool - Version rollouts. One socket, one service, one version. There is no way to run old and new side by side and shift traffic, and no health gate before traffic arrives. - Anything already behind a load balancer or an orchestrator, where the restart window is handled by draining and rescheduling. Adding socket activation there duplicates a solved problem and adds a mechanism for the next on-call engineer to learn. - Services with slow startup. The queue depth is finite and clients have timeouts, so a service that takes thirty seconds to become useful will still fail requests — the refusal has just become a timeout, which is sometimes worse because it is slower to detect. - Cases where the real requirement is not losing in-flight work. Socket activation protects the arrival path only; accepted connections die with the process regardless. ## What I would require alongside it Even where we adopt it, two things stay mandatory. Every service handles `SIGTERM` by finishing accepted work before exiting, because the socket does not cover that half. And startup stays fast, because the value of the mechanism decays with the length of the gap. I would also want the operational surprises documented before rollout, not after the first incident: that stopping the service leaves the port live and the next connection restarts it; that taking an endpoint down means stopping the socket unit; and that a crash-looping service can trip the activation rate limit and take the socket unit itself into a failed state, which presents as the port vanishing. ## How I would frame the decision Socket activation is a cheap local improvement, not an availability strategy. Where a service already ships with a socket unit, or where a small patch buys on-demand start on a crowded host, take it. Where the requirement is safe rollout, buy that at the layer that can hold two versions at once, and do not let an elegant single-host mechanism create the impression that the rollout problem has been solved.