Socket activation is often described as giving restarts that never refuse a connection. On a systemd host, what exactly keeps clients from seeing "connection refused" while the service restarts, and where does that property break down?

## Why the connection is not refused "Connection refused" on TCP means the host answered a SYN with a RST, which is what the kernel does when nothing is listening on that port. Under socket activation there is always something listening: systemd created the socket, and systemd is PID 1, which does not restart when your service does. `systemctl restart myapp.service` tears down and re-spawns the process, and the descriptor stays open in PID 1's file table the whole time. So a client connecting during the gap completes its handshake normally and its connection sits in the kernel's queue of established-but-not-yet-accepted connections. When the new process starts, it is handed the same descriptor as fd 3, calls `accept()`, and picks those connections straight up. From the client's point of view the request was slow, not failed — and "slow" is a far better failure mode than "refused", because clients retry storms and circuit breakers usually trigger on refusal. ## What this does not give you It is worth being precise, because the phrase "zero-downtime" oversells it. **Accepted connections die.** Anything the old process had already accepted belongs to that process. When it exits, those sockets close. Long-lived connections, in-flight HTTP requests and open WebSockets are all dropped unless the application handles `SIGTERM` by finishing what it has in hand before exiting. Socket activation protects the arrival path; the application still owns the drain path. **The queue is finite.** The pending queue on the listening socket has a limited depth, which `Backlog=` in the socket unit sets. A restart that takes two seconds under a trickle of traffic is invisible; the same restart under heavy arrival rate overflows the queue, and once it is full new arrivals are dropped rather than queued. Socket activation converts a certain refusal into a bounded wait, not into an infinite buffer. **Nothing is buffered above the socket.** systemd does not proxy, read or replay any bytes. It only holds the descriptor. If your client sends a request and gives up after 500 ms, the fact that the connection was accepted does not help you. ## The commands that behave differently than people expect This is the operational half of the topic, and it is where interviews go: - `systemctl restart myapp.service` — the socket stays open, connections queue. This is the case the feature exists for. - `systemctl stop myapp.service` — stops the process, but the socket is still listening, so the very next connection starts the service again. Operators who meant "take this out of service" are surprised to find it back a second later. - `systemctl stop myapp.socket` — this is what actually closes the listener. To take the endpoint down properly you stop the socket and then the service. - `systemctl restart myapp.socket` — closes and reopens the listening socket, which drops the queued connections. Not what you want during a rolling restart. ```bash systemctl restart myapp.service # process cycles, listener persists systemctl stop myapp.socket # the endpoint really goes away systemctl status myapp.service # look for the TriggeredBy: line ``` ## The crash-loop guard There is a second failure mode worth knowing. If the activated service keeps dying immediately, every queued connection triggers another start attempt, and you get a very fast activation loop. Socket units have a rate limit for exactly this: `TriggerLimitIntervalSec=` and `TriggerLimitBurst=` (defaulting to a couple of hundred activations in a two-second window). Exceed it and the socket unit itself enters the failed state and stops listening — which looks, from outside, exactly like the port disappearing. The fix is to look at why the service crashes, then `systemctl reset-failed myapp.socket` and start the socket again. An engineer who has been paged for this recognises "the port vanished after the service started crash-looping" instantly. ## How it compares with the alternatives Socket activation gives you restart continuity on one host with no coordination and no extra moving parts, and it needs no second copy of the process. What it cannot do is shift traffic between hosts, hold two versions of the service up at once, or gate traffic on a health check — for that you need something in front. The honest framing in an interview is that socket activation removes the connection-refused window during a local restart, and that everything else about safe rollout lives elsewhere.