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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 30 Jul 2013 16:07:30 +0200
lee <lee@xxxxxxxxxxxxxxx> wrote:
> Tim <ignored_mailbox@xxxxxxxxxxxx> 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


-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org




[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux