[Freeipa-devel] Should mask/unmask be part of disabling/enabling services in systemd?

Martin Basti mbasti at redhat.com
Mon Sep 22 15:05:15 UTC 2014


On 22/09/14 08:53, Martin Kosek wrote:
> On 09/19/2014 06:33 PM, Simo Sorce wrote:
>> On Fri, 19 Sep 2014 17:50:16 +0200
>> Martin Kosek<mkosek at redhat.com>  wrote:
>>
>>> On 09/19/2014 05:23 PM, Rob Crittenden wrote:
>>>> Martin Basti wrote:
>>>>> Hello list,
>>>>>
>>>>> I need to use systemd mask/unmask in ipa service.
>>>>>
>>>>> But as Honza wrote:
>>>>> "IMO masking/unmasking should be part of disabling/enabling a
>>>>> service in systemd. AFAIK in most other init systems when you
>>>>> disable a service, it has the same effect as masking the service
>>>>> in systemd - it will never be started until it is enabled/unmasked
>>>>> again. "
>>>>>
>>>>> So my questions is, should be masking part of disabling service in
>>>>> systemd, to be platform independent?
>>>>> Or should we add mask/unmask methods to
>>>>> ipaplatform.base.services.PlatformService where mask is alias for
>>>>> disable?
>>>>>
>>>>> Martin^2
>>>>>
>>>> After readinghttp://0pointer.de/blog/projects/three-levels-of-off  I
>>>> disagree that disabling in SysV is the same as masking in systemd,
>>>> though I guess it depends on the meaning of disable. According to
>>>> that page chkconfig off <service> is equivalent to systemctl disable
>>>> <service>.service, which is what we do now AFAIR.
>>>>
>>>> Why do you need to mask a service, e.g. render it completely
>>>> unstartable?
>>>>
>>>> rob
>>> I do not have full context, but looks like a good question. We only
>>> enable ipa "service" and starts via ipactl all other services. So we
>>> can disable/enable/mask services on the LDAP level, not on systemd
>>> level.
>> I do not think masking is right for now, however I'd like to chime in
>> given there is work around this.
>>
>> The current ipactl method was necessary due to issues in using systemd
>> fully, however if newer systemds have bugs about enabling/disabling unit
>> files from another one fixed then we should look into making the
>> ipa.service use ipactl *only* to enable/disable unit files.
>> This way if we can create the various unit files as eg:
>> ipa-httpd.service where the only thing we do is add an After:
>> ipa.service and then include the system's httpd.service file we will be
>> in a better situation.
>> Especially on shutdown, as no matter what changed in LDAP on shutdown
>> we do not even lookup anything and just let systemd tear down all
>> services in the ipa group (I guess there is a way to tell systemd that
>> if ipa.service goes down all it's dependent services also need to go
>> down.
>>
>> I know this is a major refactoring, but if we can pull it off, this is
>> the correct way to go with systemd integration in the longer term.
>>
>> Simo.
>>
> Probably yes, I already had a discussion with systemd folks about a native
> systemd way to manage the services. I filed a ticket:
>
> https://fedorahosted.org/freeipa/ticket/4552
>
> This shouldn't stop these patches though, especially if they are required for
> the DNSSEC feature.
>
> Martin

Back to my question.

Should we use the mask as systemd specific and use it in disable, or 
create the mask method in platform module?

IMHO, IPA is mainly used on systemd platforms, so we could add mask 
method, which can be used as alias for disabling on other systems.



-- 
Martin Basti




More information about the Freeipa-devel mailing list