systemctl uses ambiguous terms (was: Do I need avahi?)

Marko Vojinovic vvmarko at gmail.com
Tue Jul 30 16:49:21 UTC 2013


On Tue, 30 Jul 2013 16:07:30 +0200
lee <lee at yun.yagibdah.de> wrote:
> Tim <ignored_mailbox at yahoo.com.au> writes:
> > Currently, we have something "disabled" that doesn't do what we
> > expect, based on prior behaviour, nor what the word means.  You
> > have to wonder how many people are using it thinking it means
> > something else, both from the end-users, and those writing software
> > using the system.
> 
> True --- I've been thinking that disabled means disabled.  Now can you
> really question every option any software might have, especially when
> its meaning seems as clear and obvious as "disabled", because it just
> might mean something else nowadays?

Just a short note here --- "disabled" does now exactly what it used to
do back in sysV days: the disabled service would not run on boot, but
could be activated manually. The sysV services did not have the analog
of "mask", though.

What is different with systemd is the fact that now other services may
manually start a given service (which was disabled and didn't start on
boot).

This could also be done back in sysV (one service could manually
start another by issuing "service blabla start" in a script), but it
was not very convenient, since the target service might be already
running, or there could be problems with root privileges, etc.
The infrastructure that systemd introduced solves these problems in a
more systematic way, so now we can see services starting other
services all over the place. All this is still "manual", since the
target services are not being started on boot, but rather on demand.

When you think about it, there is really no way to make the difference
between root saying "systemctl start blabla" in the prompt and another
service saying the same thing in a script. It is called "manual" in
both cases.

So the systemd "disable" and the old sysV "disable" are doing exactly
the same thing, while "mask" didn't (and couldn't) exist back in sysV.

The different behavior you see today is just because starting a
service by another service was not common in sysV days. Actually, I
believe systemd provides convenient functionality for this precisely
because there was some demand to allow for services starting other
services (in a safe way), where sysV method was falling short (for root
privilege reasons etc.).

While I could agree that disable/mask terminology is not the most
intuitive one, it was retained so it wouldn't break
backward-compatibility with the meaning of "disable" in sysV.

HTH, :-)
Marko




More information about the users mailing list