mirror of
https://github.com/systemd/systemd.git
synced 2026-08-09 01:20:53 +00:00
f8f2860750
We currently blindly send the configured reload signal (e.g. SIGHUP or SIGUSR1) to the main service PID for Type=notify-reload units, even if the service hasn't installed a userspace handler. This can lead to invoking unintended default behavior (typically process termination) in daemons which later deprecate and remove their reload handler. This is a real problem we have seen in production on multiple occasions. In one particularly egregious instance, a production distributed storage service had a large percentage of its nodes all terminate at once when sent a reload signal. In this case a signal handler had been removed, but another place still sending the signal was missed. To mitigate this, introduce two new checks for Type=notify-reload services: 1. On READY=1: When the service first sends READY=1 during initial startup, we check for the handler. If it's missing, the service startup is failed with SERVICE_FAILURE_PROTOCOL. This enforces the contract that services *must* install their handler before signalling readiness. 2. On reload: Immediately before sending the reload signal, we check again. If the handler is now missing, we log a warning but still send the signal. This preserves the requested operator action while making the missing handler visible. The startup check catches definite static misconfiguration before the service is accepted as ready. The reload check is advisory because the service has already started successfully, but warns if its handler later disappears. Together these provide a best-effort safety net while preserving the agreed reload semantics.