Systemd socket activation application support limits for zero-downtime upgrades

Direct answer

Systemd socket activation keeps the listening socket open across a service restart, so new connections are queued in the kernel backlog and accepted by the new process. However, established TCP connections are not transferred to the new process; they remain owned by the old process and close when that process exits. True zero-downtime for in-flight requests requires application-level graceful drain combined with systemd shutdown tuning, not socket activation alone.

Confirmed behavior

• The socket unit owns the listening file descriptor and passes it via LISTEN_FDS/LISTEN_PID. The application must accept the inherited FD and must not call bind() or listen() on the configured port.
• While the service is stopped, the kernel queues incoming connections in the socket backlog (limited by ListenBacklog= in the socket unit and the kernel somaxconn value). systemd does not drop these queued connections.
• systemd does not migrate established connections. The old process continues to own its open file descriptors until it exits. If the old process is killed abruptly (KillMode=control-group or a short TimeoutStopSec), in-flight requests fail immediately.

Likely explanation for production zero-downtime

To avoid dropping active requests during a binary replacement, you need:

1. Application cooperation: the process must handle SIGTERM by stopping acceptance of new work, finishing in-flight requests, then exiting cleanly.
2. Service unit tuning: set KillMode=mixed (or process) and a TimeoutStopSec long enough for the longest request to complete. This lets the old process drain while the new process starts accepting from the same socket.
3. Backlog sizing: ensure ListenBacklog= and /proc/sys/net/core/somaxconn are large enough to absorb the connection spike during the restart window.

Without these, the gap between stop and start is only the accept latency; established connections are not preserved across the binary replacement.

Legacy binary limitation

Binaries that do not support inherited file descriptors cannot use native socket activation. A wrapper (e.g., socat or a small proxy) can accept the FD and forward to the legacy binary, but this adds a network hop, changes connection semantics, and does not solve the established-connection drain problem.

Verification steps

# Confirm socket unit owns the port and passes FDs
systemctl cat myservice.socket
# Look for ListenStream= and no BindToDevice conflicts

# Confirm service reads LISTEN_FDS and does not bind
systemctl cat myservice.service
# Check for Environment=LISTEN_FDS=1 or similar, and no port bind in code

# Check shutdown tuning
systemctl show myservice.service -p KillMode,TimeoutStopSec,Restart

# Observe backlog and connection states during a controlled restart
ss -lntp sport = :8080
watch -n1 'ss -tan state established sport = :8080 | wc -l'

One diagnostic detail needed

Does your application currently handle SIGTERM for graceful shutdown, or does it exit immediately on signal receipt? This determines whether TimeoutStopSec tuning alone is sufficient or whether code changes are required.