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

[Tom Gundersen]

On Tue, Nov 18, 2014 at 2:58 PM, Didier Roche <didrocks at ubuntu.com> wrote:
>> This I think should be considered a bug in the unit file. If a unit
>> has a /usr/lib symlink, then it is statically enabled (i.e.,
>> 'enable'/'disable' has no effect), so it should not install symlinks
>> in /etc, and hence not have an [Install] section. At least with the
>> current semantics.
>
>
> Shouldn't then systemctl status detects that there is a symlink in /usr and
> list it as a static unit instead of disabled? (or even better: warn that the
> unit is mis-formatted).
> The current "disable" status would let the admin think if he doesn't know
> about the implementation that this unit will never be active until I
> systemctl start it explicitly, which isn't the case.

Yeah, that makes sense. Would be happy to take a patch for this.

>> I get where you are coming from, but presets will give you the same
>> result, no?
>
> Apart from what we discussed on this thread with Martin about the "/etc"
> clutterness having distro-specific information and not only system ones,
> right.
>
> However, this is kind of a complex case in D/U where we have the policy to
> start most of the service on package installation. For instance, if you apt
> install docker.io, people using those distros will expect to be then able to
> do $ docker run <…> (which starts the docker service through socket
> activation).

Hm, not following this last paragraph. Are you saying we are missing
something to do with start-on-install?

> This would be maybe a nice way for the admin to know what's coming from a
> distribution default or not. However, let's say I want to ensure that ssh
> will always be available on my server, I would (even if it's in my server
> preset) then systemctl enable openssh, no matter whatever future preset
> updates does (like disable it in the next batch upgrade).
>
> With a shared distro/admin /etc, we have no way to take that fact into
> account and the next one would follow distro policy, right?
> Also, after running systemctl enable opensshn, systemctl status openssh will
> still say "enabled (preset)" even if the admin wanted to "stick it for good"
> as it's part of the preset.

This is up to the distro I guess, but I would have thought that
presets should only be applied on install-time, and not on upgrade.

>>> - systemctl enable <unit> will duplicate the symlink in /etc
>>
>> I guess this should also be dropped (though the situation here is
>> weird as it anyway is a noop). Maybe a warning should be printed.
>
>
> agreed as well, or, this would be a way for the sysadmin to "stick" this
> unit/service whatever future distro will choose in the next upgrade.

Could be, yeah, but moving from static to opt-in during an upgrade
sounds like a packaging bug to me, so hopefully this situation would
never be encountered in production.

>> Well, the meaning we have been using so far is that statically enabled
>> units are things that does not really make sense to disable (which is
>> different from it being enabled by default), and for all other units
>> the way to enable/disable them (be it by default or manually) is by
>> installing symlinks in /etc. If the admin wants to insist to ignore
>> the "does not make sense to disable part" and really force something
>> to never start, then masking is the tool for that. Either way, the
>> admin should never (need to) go poking in /etc manually, but use
>> systemctl as the interface.
>
>
> Indeed, I'm getting where you are coming from now and see the real
> difference you mean with default symlinks in /usr. However, it would seem
> weird to me to have to systemctl mask plymouth-quit.service for instance
> without knowing the internals of systemd to be able to really "disable" (I
> know the term is wrong, just trying to feel how they could interprete it) a
> certain class of units.

Hm, I didn't follow this paragraph, could you rephrase?

>>> - The status reported with systemctl is still disabled when it's not.
>>
>> We can probably improve on that. I guess no one really explored the
>> case of static units with [Install] sections. Even if we end up
>> thinking of these as bugs, people can still end up with them, so we
>> should probably make sure our tools report something sensible.
>
>
> Agreed, I can open a bug independently of this discussion and work on this,
> as it seems we all agree that this status report needs to be improved even
> with units not following the current expected semantics.

Great!

>> My take on this is: make sure presets are applied on "firstboot"
>> (which I think they are), so empty /etc works just fine, and then
>> improve on systemctl to better show the distinction between 'enabled
>> by default' or 'enabled by choice' (and same for 'disabled').
>
>
> Thanks again for your feedback. If the whole proposal is rejected, I think
> we'll try to have debian following this as a first step.

Sounds good, but let's see if maybe Zbigniew or Lennart have any
comments on your proposal (if my memory serves me right they did most
of the work in this area).

Cheers,

Tom