[systemd-devel] /usr vs /etc for default distro units enablement

[Didier Roche]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20141118/82127d17/attachment-0001.html>