On 09/07/14 05:35 AM, users-request@lists.fedoraproject.org wrote: On 7 Date: Wed, 09 Jul 2014 00:36:37 -0700 From: Joe Zeff On 07/08/2014 11:40 PM, lee wrote:
When something is disguised or hidden, it is not disabled. It is camouflaged or concealed. Camouflage, concealment, hiding, disguise and masking can all be used for*preventing* from being disabled.
No. When a service is disabled it can still be started after boot, but when it's masked, it can't be started at all.
Do understand that I'm defending neither systemd nor the deveolper's choice of terminology. I'm merely correcting what looks like a misstatement of how it works.
Yes! And how it *works* is not what that term, used normally describes. Which is the point being made. 'Disabled' should imply 'NEVER' 'Masked' is not a word which should be used in this context.
Selinux got the terms correct, IMHO there is NO reason why systemd should not use the same terms:
ENABLED means ALWAYS PERMISSIVE means SOMETIMES DISABLED means NEVER
These are the start-up default states and should have no effect on using start or stop directly. Systemd however mis-manages this as well, so that you cannot start a 'masked' service
So 'masked' is actually NEVER NOT EVEN WHEN YOU WANT IT. and DISABLED means SOMETIMES, but there is no way to set a state where the computer cannot under any circumstances but you can MANUALLY.*
This thread contains numerous instances of why systemd is not well architected, although what it does do, it seems to do well. What it tries to do seems to be a 'reach which exceeds its grasp'. And to boot, the documentation, although extensive is far too abstract and blatherfull to be actually useful.
Geoff
*I mean that I should not have to 'unmask', 'start' and 'mask' the service to achieve an 'only-when-*I*-want-it' start-up of a service. Setting 'disabled' means that the system can start it whenever it feels the need.
On 07/09/2014 05:51 PM, R. G. Newbury wrote:
On 09/07/14 05:35 AM, users-request@lists.fedoraproject.org wrote: On 7 Date: Wed, 09 Jul 2014 00:36:37 -0700 From: Joe Zeff On 07/08/2014 11:40 PM, lee wrote:
When something is disguised or hidden, it is not disabled. It is camouflaged or concealed. Camouflage, concealment, hiding, disguise
and
masking can all be used for*preventing* from being disabled.
No. When a service is disabled it can still be started after boot, but when it's masked, it can't be started at all.
Do understand that I'm defending neither systemd nor the deveolper's choice of terminology. I'm merely correcting what looks like a misstatement of how it works.
Yes! And how it *works* is not what that term, used normally describes. Which is the point being made. 'Disabled' should imply 'NEVER' 'Masked' is not a word which should be used in this context.
Selinux got the terms correct, IMHO there is NO reason why systemd should not use the same terms:
ENABLED means ALWAYS PERMISSIVE means SOMETIMES DISABLED means NEVER
These are completely unrelated terms. in services start language "enabled" means "start at boot" and disabled "do not start at boot" .. and that's all .. systemd added the automatically dependency start : if the foo service is a dependence of bar service, at bar start also foo will start even if it is not enabled (which is good!) (and from my point of view easier for the admins and users alike) only when you want to _forbid_ the start of an service you will "mask" it: i see the term like a blanket the covers the subject that stops to be there. (as you probably seen mask mean just ln -s foo.service /dev/null )
These are the start-up default states and should have no effect on using start or stop directly. Systemd however mis-manages this as well, so that you cannot start a 'masked' service
So 'masked' is actually NEVER NOT EVEN WHEN YOU WANT IT. and DISABLED means SOMETIMES, but there is no way to set a state where the computer cannot under any circumstances but you can MANUALLY.*
what is exactly your use case? what do you want to achieve?
..snip..
Geoff
*I mean that I should not have to 'unmask', 'start' and 'mask' the service to achieve an 'only-when-*I*-want-it' start-up of a service. Setting 'disabled' means that the system can start it whenever it feels the need.
only-when-you-want-it includes the case of being of dependency of something you start? i mean it would be logical that for a foo.service disabled (and dependency of bar.service) to start when you manually (systemctl enable && start) bar.service also to start foo.service. after all you really wanted to start the the bar.service and by dependency chain also foo.service..
So.. what is exactly the problem? What do i miss in your problem description?
Adrian
Adrian Sevcenco Adrian.Sevcenco@cern.ch writes:
These are completely unrelated terms. in services start language "enabled" means "start at boot" and disabled "do not start at boot" .. and that's all ..
If you want to see it this way, then systemd misunderstands things so that "disabled" means to start something eventually, which is bs. Without systemd, and for everyone and everything else, disabled means disabled, like "cannot be started".
systemd added the automatically dependency start : if the foo service is a dependence of bar service, at bar start also foo will start even if it is not enabled (which is good!) (and from my point of view easier for the admins and users alike)
Why would it be easier for anyone to express dependencies than it is to make it so that things start in a particular order?
When bar depends on foo such that it doesn't work without foo, it's up to the package management to know this dependency and to install foo when I install bar. This is not a job for the init system.
Starting something that is not enabled, i. e. disabled, is a bug, and there's nothing good about it. There's also nothing good about starting something that isn't needed or wanted (which is why it is disabled) just because something else which is needed or wanted is started.
It /can/ be a good thing when it's possible to start something which is not started during booting. That it can be started and under what conditions exactly it will be started has to be entirely clear, and there needs to be an option to ask root whether it should be started or not. Systemd doesn't have this clarity, and it doesn't ask, and there's nothing good about that.
only when you want to _forbid_ the start of an service you will "mask" it:
No, I would disable it.
"R. G. Newbury" newbury@mandamus.org writes:
So 'masked' is actually NEVER NOT EVEN WHEN YOU WANT IT. and DISABLED means SOMETIMES,
They confuse "masked" with "disabled" and "disabled" with "ondemand" and deny to fix that.
This thread contains numerous instances of why systemd is not well architected, although what it does do, it seems to do well.
There was also someone reporting that it doesn't do what it's supposed to. That seemed to be because it's so complicated that even the makers of the distribution didn't manage to set it up correctly.
Systemd is one more thing designed to take the control of our computers away from us. Think of it: All major distributions have no choice but to use it, it takes over all kinds of things and intentionally confuses developers and users alike through means that were already pointed out. And interestingly, ppl are trying to explain how systemd is not bad while nobody explains why it is good.
-
Adrian Sevcenco -
lee -
R. G. Newbury