Socket‑activated service stalls on upgrade: Type=simple vs Type=notify behavior

Direct Answer

To prevent stalls during an upgrade, use Type=notify. While Type=simple tells systemd the service is ready the moment the process forks, Type=notify forces the manager to wait for a readiness signal from the application. This ensures the new binary is fully initialized and listening on the inherited socket before systemd attempts to hand off new incoming connections to it.

Type=simple vs. Type=notify Behavior

The choice between these types determines how systemd manages the lifecycle of your service during a package upgrade or a restart:

• Type=simple: systemd assumes the service is ready as soon as the execution starts. If the upgraded binary takes several seconds to load shared libraries or initialize internal state, systemd may route new socket connections to a process that is not yet calling accept(), leading to stalls or timeouts.
• Type=notify: systemd waits until the process sends a READY=1 message via the DBUS socket. This is the safer choice for socket-activated services because it guarantees the process is capable of handling traffic before the transition is finalized.

Practical Implications for Upgrades

When pacman replaces a binary on Arch Linux, the running process remains in memory, holding the open file descriptor to the old code. To migrate without dropping existing connections:

1. The old process continues serving existing clients until it is explicitly terminated.
2. A systemctl restart creates a new instance using the updated binary.
3. The new instance inherits the already-open socket from systemd manager.
4. If using Type=simple, systemd might consider the new instance "active" immediately, but if the binary is still initializing, new connections hitting the socket buffer may be dropped or delayed.

Verification and Diagnostics

To verify that the new binary is actually serving traffic after an upgrade, use the following commands:

Command	Purpose
ls -l /proc/$(pid)/exe	Confirms the running process is using the new binary path.
ss -ltnp | grep :	Shows which PID is currently actively listening on the socket.
journalctl -u -f	Checks for "Service ready" logs (if using Type=notify).

Note: This analysis assumes your application supports the systemd notification protocol (e.g., via libsystemd). If the application does not support notifications, using Type=notify will cause the service to timeout.