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
