[Freeipa-devel] [PATCHES] 0039-0040 systemd ipactl fixes

[Alexander Bokovoy]

On Mon, 15 Jul 2013, Martin Kosek wrote:
>On 07/11/2013 05:03 PM, Alexander Bokovoy wrote:
>> On Thu, 11 Jul 2013, Ana Krivokapic wrote:
>>> On 07/11/2013 11:38 AM, Alexander Bokovoy wrote:
>>>> On Thu, 11 Jul 2013, Alexander Bokovoy wrote:
>>>>> On Wed, 10 Jul 2013, Ana Krivokapic wrote:
>>>>>> On 07/08/2013 08:32 AM, Alexander Bokovoy wrote:
>>>>>>> On Thu, 20 Jun 2013, Ana Krivokapic wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Attached patches fix systemd and ipactl related bugs:
>>>>>>>>
>>>>>>>> https://fedorahosted.org/freeipa/ticket/3730
>>>>>>>> https://fedorahosted.org/freeipa/ticket/3729
>>>>>>> NACK. For me upgrade case fails (rpm -Uhv), dirsrv didn't restart on
>>>>>>> upgrade properly and everything else has failed afterwards.
>>>>>>>
>>>>>>
>>>>>> This was caused due to 'systemctl is-active' returning exit status 3
>>>>>> ('activating'), and our code treating the non-zero exit status as a
>>>>>> failure. I
>>>>>> handled this case in the updated patch.
>>>>>>
>>>>>> As for the ipa.service and dependency ordering, I have done some further
>>>>>> testing
>>>>>> and found out the adding the '--ignore-dependencies' switch alone solves the
>>>>>> shutdown issue. So I think that no modification of ipa.service file is
>>>>>> necessary.
>>>>>>
>>>>>> Updated patches are attached.
>>>>> This is much better. However, 'ipactl stop' doesn't stop ns-slapd and
>>>>> dogtag:
>>>> What's important is the fact that now I can issue reboot and VM
>>>> restarts, not hangs, and then IPA starts properly on boot -- this is
>>>> because when ns-slapd gets a signal from systemd, it automatically shuts
>>>> itself down properly and the same happens to dogtag. This is good
>>>> enough so that I push current patches to master but please proceed on
>>>> fixing 'ipactl stop' issue.
>>>>
>>>>
>>>
>>> Thanks for catching that. I am attaching a patch which should solve this issue.
>> Works now, I tried stop/start/restart, all processes were properly addressed.
>>
>> Thanks!
>>
>
>Is that an ACK? If yes, please push the patches :-)
It is already in master, I only forgot to respond on the list:
af7807aacc6cf1beb25e53483b54bd599bd6421d

-- 
/ Alexander Bokovoy