forked from systemd/systemd
-
Notifications
You must be signed in to change notification settings - Fork 2
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
core: introduce dependency symlink mask
This patch allows masking of .wants symlinks in /usr/lib by /dev/null symlinks in /etc. IOW it gives the possibility to mask a dependency symlink (in .wants or .requires), assuming that the later being located in a directory having a 'lower' precedence. As a consequence a dependency symlink mask in /etc/ will mask all equivalent dependency symlinks located in directories such as /run, /usr/lib. And a dependency symlink mask in /usr/lib will has no effect on a dropin symlink located in /run or /etc. Consider the following example: /etc/systemd/system/foo.service.wants/bar.service -> /dev/null /usr/lib/systemd/system/foo.service.wants/bar.service -> ../bar.service service 'foo' was installed during a package installation with a dependency on 'bar' and later sysadmin decided to disable this dependency by adding a mask in /etc/. This results in service 'bar' not being pulled in by 'bar' anymore. The primary use case is to allow a clean separation between service activation/deactivation done during package installations/updates and those done by sysadmin. Assuming that distro dependency symlinks happens in /usr/lib only, the sysadmin is now able to disable persistently a service by creating a mask in /etc/. This mask will take precedence over any distro policies (usually defined by presets) defined in /usr/lib. The distro policies (presets) are now free to be changed without interfering with the configuration done by the sysadmin (if any). They will still be preserved and will still be taken into account. The assumption on distros creating symlinks in /usr/lib only is currently not met since this happens in /etc/. However the dropin symlink mask is the first step to achieve this clean separation. Later changes will ensure that dropin symlinks created during package installations/updates will happen in /usr/lib only. See issue systemd#4830. In order to implement the masking of dependency symlinks properly, this patch defers the handling of those dependencies until all involved units are fully loaded. This way all units and especially their aliases are known and a mask can be effective on a specific unit including all of its aliases. This is due to the way we currently handle the unit aliases (how a unit and its aliases are "lazily" merged) and also due to the fact that we can't remove dependencies added to a unit (until a full daemon-reload happens). As an example: /etc/.../a.service.wants/b1.service -> /dev/null /usr/.../a.service.wants/b.service -> ../b.service and 'b1' is an alias of 'b'. In this example, dropin symlink dependencies pulling 'b' or any of its aliases (including 'b1') will be masked. This patch also changes a rather odd behavior that nobody sane should rely on: a .wants symlink to /dev/null was masking the unit the symlink was refering to. Therefore: /etc/.../a.wants/b.service -> /dev/null would have masked 'b' service. Whereas now, it only masks the corresponding dependency symlinks defined in a.wants/ directories. It also changes the following weird case: /etc/.../a.service.wants/b.service -> ../c.service where 'b' defines an alias for 'c'. I'm not sure why symlinks were used to define dependencies in .wants/.requires in the first place whereas a simple empty file would have been sufficient and unambiguous. With this patch applied, no more aliases are defined this way.
- Loading branch information
Showing
4 changed files
with
225 additions
and
13 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters