Zbigniew Jędrzejewski-Szmek
d59cae6ceb
The new link-executor-shared option is similar to the existing link-udev-shared: when set to false, we link to the static versions of our internal libraries. The resulting exuctor binary is fairly large, about as large as libsystemd-core (14 MB without lto, 8 with lto). This is intended as a workaround for the fuckup with the pinned executor binary: when an upgrade is performed, the package manager will install new version of the libraries and new version of the code, and some time later reexecute the managers. This creates a window when the pinned executor binary will fail to execute. There are two factors which make the issue easier to hit: - when the distribution uses a finely-grained shared-lib-tag. E.g. Fedora uses version-release as the tag, which means that the issue occurs on every package upgrade. This is the right thing to do, because the ABI of our internal libraries is not stable at all, so replacing the library from a different version in place creates a window where our programs may crash or misbehave. - when the distribution doesn't immediately reexec all the managers after upgrade. In early versions of systemd, we used to hammer the machine during upgrade, doing daemon-reexecs repeatedly. This works, but is ugly and wasteful. Doing the reexecs while the upgrade is in progres also creates a window where a mix of old and new configs or both is loaded. Users are particularly annoyed by those reloads if there is some issue in the configuration causing us to emit warnings on every reexec. Doing the reexecs once after the new configuration and libraries have been put in place is nicer. The pinning of the executor binary breaks upgrades and in particular it penalizes the distributions which make use of the features which were previously added to avoid bugs and inefficiency during upgrades. When the executor is linked statically, there is a smaller chance that it'll fail to load libraries. The issue can still occur because other libraries, not our own, are linked dynamically.
System and Service Manager
Details
Most documentation is available on systemd's web site.
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