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

[Lennart Poettering]

On Tue, 18.11.14 12:11, Didier Roche (didrocks at ubuntu.com) wrote:

> 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/.

Distros really should use "systemctl preset" for this. It's what it is
for. 

If no preset policy is installed "systemctl preset" is actually
equivalent to "systemctl enable", but it allows admins to install
their own policy which then takes effect.

Really, distributions should *not* use "systemctl enable" in
postinst. It breaks presets for zero gain.
knowledgable admins.

If the admin should be able to disable/enable a service during normal
operation as part of his normal workflow then it should *not* be
enabled via symlinks in /usr, but instead carry [Install] and be
enabled by the postinst script via "systemctl preset".

> - We are mixing sys admin information and distro default choices in the same
> directories, and can't tell apart what is what.

You can actually. There's "systemctl preset-all" for example which
brings the system back into the exact choices of the upstream distro.

> 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.

Overriding symlinks with symlinks to different targets is difficult,
as systemd only really cares about the symlink names, and not so much
about the targets.

> 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.

As mentioned above: units that carry [Install] and are also enabled
via /usr/lib/ are broken really. Either you use [Install] and thus ask
systemd to manage the symlinks in /etc for you via commands like
systemctl enable/disable/preset, or you say that systemctl shall not
manage the symlinks and instead create a static on in /usr/lib. But
having a unit that is both managed and unmanaged doesn't really make sense.

> - 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.

Yeah, symlinks in .wants/ are just about creating dependencies, not
about overriding units really...

> Part of the discussion on #systemd pointed out that the admin should then
> use systemctl mask <unit>. However, that means:

Hmm, "systemctl mask" is really nothing we should advertise to users
or admins. It's a last resort tool. Should not appear in normal workflows.

Lennart

-- 
Lennart Poettering, Red Hat