Dmitri Pal wrote:
> On 09/24/2014 03:29 PM, Rob Crittenden wrote:
>> Dmitri Pal wrote:
>>> On 09/24/2014 02:07 PM, swartz wrote:
>>>> On 9/24/2014 9:05 AM, Ade Lee wrote:
>>>>> Forwarding to a couple of colleagues of mine who will be taking
>>>>> point on
>>>>> this.
>>>>>   From what I can see, the CS.cfg is truncated.  Fortunately, I
>>>>> believe it
>>>>> is reparable.
>>>>> Ade
>>>> I've been in contact with Endi and Ade. It was a truncated config file
>>>> as per msg above.
>>>> Endi had emailed me a restored config.
>>>> I can happily say that my IPA instance is back in operation.
>>>> Thank you all.
>>>> For anyone else reading this:
>>>> For me this config truncation happened after a 'yum update'.
>>>> Perhaps shutting down the IPA stack before doing package updates might
>>>> be more advisable.
>>> Is there any chance to detect which package caused this truncation?
>> It was almost certainly related to IPA, if not ipa-upgradeconfig
>> directly. For any number of reasons it may write directly to CS.cfg
>> without stopping the service first. It may also call the dogtag-provided
>> pki-setup-proxy which also doesn't stop the service before touching
>> CS.cfg.
>> The upgrader will then determine if any changes were made and restart
>> the service.
>> rob
> So is it a race condition? Something does not sound right.

What I don't understand is: if dogtag always writes CS.cfg on exit, why
does this work the majority of the time?

But anyway, it sounds like we need to shut down dogtag every time we
touch CS.cfg which isn't a big deal but it will change the way we do
some things.


Manage your subscription for the Freeipa-users mailing list:
Go To for more info on the project

Reply via email to