Re: Why do we use systemd

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

 



On 07/09/2014 05:51 PM, R. G. Newbury wrote:
> On 09/07/14 05:35 AM, users-request@xxxxxxxxxxxxxxxxxxxxxxx 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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

-- 
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