mirror of
https://github.com/systemd/systemd-stable.git
synced 2025-02-28 17:57:25 +03:00
11e11fd57a
Before, when interating over unit files during preset-all, behaviour was the following: - if we hit the real unit name first, presets were queried for that name, and that unit was enabled or disabled accordingly, - if we hit an alias first (one of the symlinks chaining to the real unit), we checked the presets using the symlink name, and then proceeded to enable or disable the real unit. E.g. for systemd-networkd.service we have the alias dbus-org.freedesktop.network1.service (/usr/lib/systemd/system/dbus-org.freedesktop.network1.service), but the preset is only for the systemd-networkd.service name. The service would be enabled or disabled pseudorandomly depending on the order of iteration. For "preset", behaviour was analogous: preset on the alias name disabled the service (following the default disable policy), preset on the "real" name applied the presets. With the patch, for "preset" and "preset-all" we silently skip symlinks. This gives mostly the right behaviour, with the limitation that presets on aliases are ignored. I think that presets on aliases are not that common (at least my preset files on Fedora don't exhibit any such usage), and should not be necessary, since whoever installs the preset can just refer to the real unit file. It would be possible to overcome this limitation by gathering a list of names of a unit first, and then checking whether *any* of the names matches the presets list. That would require a significant redesign of the code, and be a lot slower (since we would have to fully read all unit directories to preset one unit) to so I'm not doing that for now. With this patch, two properties are satisfied: - preset-all and preset are idempotent, and the second and subsequent invocations do not produce any changes, - preset-all and preset for a specific name produce the same state for that unit. Fixes #3616.
systemd - System and Service Manager
Details
General information about systemd can be found in the systemd Wiki.
Information about build requirements are 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 file for information 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.