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.
System and Service Manager
Details
Most documentation is available on systemd's website.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list, join our IRC channel #systemd on libera.chat or Matrix channel
Stable branches with backported patches are available in the stable repo.
We have a security bug bounty program sponsored by the Sovereign Tech Fund hosted on YesWeHack
Repositories with distribution packages built from git main are available on OBS, and also repositories with packages built from the latest stable release