d361e5ba34
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 signal handler validation for Type=notify-reload services. We check both SigCgt (traditional handlers via sigaction) and SigBlk (blocked signals for signalfd) to detect valid handler configurations: 1. On first 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 aborted with Result=protocol. 2. On reload: Immediately before sending the reload signal, we check again. If the handler is missing, we log a warning but still send the signal. The rationale is that a missing handler at first startup represents a definite misconfiguration that should be caught early. A missing handler at reload time is warned about, but we defer to the operator's judgement since the service already started successfully. These checks are a best-effort, pragmatic safety net. They are naturally racy, but in practice they prevent the common class of bugs from static misconfiguration or software updates.
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