[Freeipa-users] PKI-CA fails to start (broken config after update?)

[Ade Lee]

On Wed, 2014-09-24 at 16:24 -0400, Rob Crittenden wrote:
> 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?

Dogtag does not write CS.cfg on exit (like 389).  Rather, if there are
changes to CS.cfg, they will be committed and the file will be changed
and the in-memory version of CS.cfg will be written at that time.

I think what we're seeing is two different things modifying the CS,cfg
at the same time (or at least within the time frame of whatever file
buffering is going on).  In other cases where I've seen this, I see
CS.cfg end up the size of n * file buffer.

Shutting down CA before changing CS.cfg is a way of preventing access by
more than one source at the same 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.
> 
> rob
>