Zbigniew Jędrzejewski-Szmek
fb39af4ce4
If we had a configuration setting from a configuration file, and it was removed, we'd still remember the old value, because there's was no mechanism to "reset" everything, just to assign new values. Note that the effect of this is limited. For settings that have an "ongoing" effect, like systemd.confirm_spawn, the new value is simply used. But some settings can only be set at start. In particular, CPUAffinity= will be updated if set to a new value, but if CPUAffinity= is fully removed, it will not be reset, simply because we don't know what to reset it to. We might have inherited a setting, or we might have set it ourselves. In principle we could remember the "original" value that was set when we were executed, but propagate this over reloads and reexecs, but that would be a lot of work for little gain. So this corner case of removal of CPUAffinity= is not handled fully, and a reboot is needed to execute the change. As a work-around, a full mask of CPUAffinity=0-8191 can be specified.
systemd - System and Service Manager
Details
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 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 or join our IRC channel.
Stable branches with backported patches are available in the stable repo.