On 09/19/2014 06:33 PM, Simo Sorce wrote:
> On Fri, 19 Sep 2014 17:50:16 +0200
> Martin Kosek <mko...@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 reading http://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:


This shouldn't stop these patches though, especially if they are required for
the DNSSEC feature.


Freeipa-devel mailing list

Reply via email to