Systemd Socket Activation: Can Reload Preserve Existing Connections?

Answer: No automatic guarantee; the service must implement a graceful hand‑over.

Systemd guarantees that the listening socket inherited via socket activation remains open across a reload, but it does **not** transfer the accepted connection file descriptors from the old process to the new one. If the old process exits or closes those sockets, clients see a reset (RST). Therefore zero‑downtime reload depends entirely on the service draining or passing those sockets itself.

Confirmed facts (from research)

• The listening socket stays open on reload in systemd v237, v240, and v252 (v237 only if ExecReload is defined; otherwise it could close the socket).
• Accepted sockets are not automatically moved; they are closed when the old process terminates unless the service keeps them open.
• Without explicit handling, a reload causes client‑visible connection resets regardless of systemd version.

Likely explanation

The behavior hinges on the ExecReload directive and the service’s signal handling. If ExecReload sends a signal (e.g., SIGUSR1) that the binary interprets as “stop accepting new connections and finish existing ones”, the old process can keep the accepted sockets open until they finish, then exit. The new instance, started by systemd, inherits the same listening socket and can continue accepting traffic.

Minimal unit configuration for zero‑downtime reload

[Unit]
Description=Example socket‑activated daemon

[Socket]
ListenStream=12345

[Service]
Type=notify          # or Type=simple with explicit signal handling
ExecStart=/usr/local/bin/mydaemon
ExecReload=/bin/kill -s SIGUSR1 $MAINPID
# The daemon must:
# 1. On SIGUSR1, stop calling accept() and wait for existing connections to close.
# 2. Optionally pass those sockets to a child via UNIX domain socket or fd‑passing.
# 3. Exit only after all accepted sockets are closed.

With this setup, systemctl reload myservice.socket (or systemctl reload myservice.service) will send SIGUSR1, allowing the old instance to drain connections while the listening socket stays open, and the new instance will take over without client‑visible reset.

Missing diagnostic detail

If you cannot modify the binary to handle SIGUSR1, please confirm whether the daemon already ignores SIGTERM/SIGINT until it finishes existing work, or whether an external helper (e.g., systemd‑socket‑activate with fd‑passing) is available. This detail determines whether the above unit changes are sufficient or if additional wrapper logic is required.