<html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> 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/. 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" - 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. - We are mixing sys admin information and distro default choices in the same directories, and can't tell apart what is what. 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. 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. 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. Part of the discussion on #systemd pointed out that the admin should then use systemctl mask <unit>. However, that means: - The admin can't retarget a default installed unit without recreating another unit file - There are 2 commands to "disable" an unit: mask for some, disable for others, this can bring confusion and admins won't know the semantic difference between the two (and indeed this is rather technical and unintuitive) - The status reported with systemctl is still disabled when it's not. Tested with systemd 216 on fedora 21 and systemd 215 on ubuntu vivid. 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. Cheers, Didier <meta http-equiv="content-type" content="text/html; charset=utf-8"> </body> </html>