Didier Roche wrote on 18/11/14 11:11: > Fedora doesn't enable and start all units on package installation: there > are some preset files, based on flavors, which is basically the policy > stating which units to enable/disable by default. Some other units are > always enabled (unless masked), by using symlinks directly shipped with > the package like in /usr/lib/systemd/system/multi-users.target.wants/ > for intance. Contrary to that, Debian/Ubuntu has the policy to > enable/start services and facilities on package installation during > postinst. This is done (indirectly) via "systemctl enable", which > creates symlinks in /etc/systemd/system/*.wants/.
I believe that it is generally discouraged to use "systemctl enable" indirectly or otherwise during postinst. You should instead use systemctl preset which uses information in various distro provided *.preset files that contain rules for which units should be enabled or disabled. This allows a "default" /etc tree of symlinks to be repopulated easily. > This has 3 drawbacks: > - Duplicate symlinks for the same targets between /etc and units enabled > in /usr/lib for units which are already enabled via /usr/lib, if the > admin runs "enable" If a package ships a unit enabled via a symlink in /usr/lib, then that same package should ensure the systemd unit does NOT have an [Install] section. Doing so is confusing to the user, so if the packager makes this decision, he should follow it through properly. If this is an upstream make-install rule, then it should be fixed upstream to make it consistent - again the rules is "if you ship a symlink in /usr/lib, you should not have an [Install] section" (I think this is good advice but I'm sure someone will correct me if I'm wrong!). I won't discuss the merits of shipping an enabling link in /usr/lib. > - Wrt. the "golden image, /etc reset" approach of reducing base os > installation defaults in /etc, this is another instance of "always needs > to be there" clutter in /etc. If the package default is to start the > service, then it's better to just ship that wants.d/ symlink in the > package (and thus in /usr) instead of always having to create the > symlink in /etc at package install time or after a factory reset. Yes and no. Depending on your use case perhaps shipping it in /usr/lib is OK (e.g. an embedded system that still wants to support factory reset), but I'd say that generally speaking, this is what *.preset files and systemctl preset is meant to achieve. They represent the distro rules, but still give users full control after the default rules are applied. > - We are mixing sys admin information and distro default choices in the > same directories, and can't tell apart what is what. /etc is admin, and the distro *default* is applied there (via *.preset files) but the admin still has full control. > We were thus thinking about having all default distro choices shipping > target symlinks in /usr/lib, and having the administrator overrides this > in /etc via systemctl. This could look similar to masking a unit, i. e. > a symlink "/etc/.../wants.d/foo -> /dev/null" overrides > "/usr/lib/.../wants.d/foo -> ../foo.service", and would be an explicit > representation of "the admin does not want foo.service to autostart" in > /etc. I really don't think that's a good idea. Just use preset and setup /etc/ by default, but let the admin override it as needed. > However, we did notice the following: taking an unit, with an [Install] > section and a symlink to enable in via that target in /usr/lib: > - systemctl status <unit> will report "disabled", where it's actually > enabled and starting for that unit. This is a bug which should be fixed > in any case, as "disabled" is outright wrong. This is why I stated above that if you ship an enabling symlink in /usr/lib, you should also remove the [Install] section. I still think this is the right solution here. > On IRC it was suggested > that those are "static" units, but then it should say at least that. > - systemctl enable <unit> will duplicate the symlink in /etc > - If we ln -s /dev/null /etc/<…>/<…>.wants/<unit>, then systemctl status > <unit> will display the unit as being enabled, and it will activated > once the target is reached. This is also counterintuitive, as usually > this means to mask/completely disable the unit. I don't think this is a good idea. I really think you should just use *.preset files properly and generally discourage the shipping of any enabling symlinks in /usr/lib. And if you do have some special cases where you want to do that, have a policy that bans an [Install] section in such units. > It will be great if we can come to some common grounds on how we should > separate admin choices and default distro choices, while still working > on the "remove /etc default distro configuration" . I'm happy to give a > hand on the desired solutions there. I think the following is best practice and solves the general issues here: 1. Discourage strongly the shipping of enabling symlinks in /usr/lib (but aliases are probably OK). 2. If a special case arises where a an enabling /usr/lib symlink is deemed the best option, the unit must not have an [Install] section. 3. Do not use "systemctl enable myunit.service" (directly or indirectly) in packaging postinst, but rely on "systemctl preset myunit.service" instead to capture the distribution (or spin) rules. This deals means: 1. distro installs the default setup for users, but admins can override later 2. factory reset works fine (assuming "systemctl preset-all --preset-mode=enable" is run after reset) 3. systemctl status will work (because only units without [Install] sections will have enabling links in /usr/lib) Have I missed something or does this sound good to you too? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel