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
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
