pcp
[Top] [All Lists]

RE: [pcp] pmcd restart race condition

To: "'Frank Ch. Eigler'" <fche@xxxxxxxxxx>, "'Martins Innus'" <minnus@xxxxxxxxxxx>
Subject: RE: [pcp] pmcd restart race condition
From: "Ken McDonell" <kenj@xxxxxxxxxxxxxxxx>
Date: Sat, 3 Oct 2015 07:05:26 +1000
Cc: "'pcp developers'" <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <y0my4flump3.fsf@xxxxxxxx>
References: <560EB93A.6020606@xxxxxxxxxxx> <y0my4flump3.fsf@xxxxxxxx>
Thread-index: AQDa6HMPGg5ajBkvr3p5+HMH2wbsCQILWs5zoDR3AUA=
> -----Original Message-----
> From: pcp-bounces@xxxxxxxxxxx [mailto:pcp-bounces@xxxxxxxxxxx] On
> Behalf Of Frank Ch. Eigler
> Sent: Saturday, 3 October 2015 4:53 AM
> To: Martins Innus <minnus@xxxxxxxxxxx>
> Cc: pcp developers <pcp@xxxxxxxxxxx>
> Subject: Re: [pcp] pmcd restart race condition
> 
> Martins Innus <minnus@xxxxxxxxxxx> writes:
> 
> >     I'm seeing some sort of race condition that I haven't been able
> to
> > track down.  If you create a bunch of
> > /var/lib/pcp/pmdas/<pmda>/.NeedInstall files and then restart pmcd,
> > sometimes, but not always, all the pmda/pmcd logs are gone, and only
> > the .prev versions remain [...]
> ...
> That's a very good point. ...  Some of those Install scripts
> restart pmcd via the same rc script, so nestedness and concurrency is
> easily possible.
> 
> Perhaps the NeedInstall machinery should be removed entirely from the
> pmcd rc script, and let the rpm %post-install (or equivalents) handle
> them.

The .NeedInstall machinery was (comparatively) recently added.  The
.NeedRebuild machinery for the PMNS is much older and gets done in the
foreground.

Rather than a packaging post-op which has to be redone for each of the 3 or
more packaging modes we support, I think it would be preferable to have
pmda_setup _not_ run in the background ... this would serialize each of the
pmda ops controlled by the .NeedInstall or .NeedRemove files.  Except for
the first pmcd start after a package install or upgrade the .Need* files
won't exist, so the delay from checking in the foreground would be small.

Just not running pmda_setup in the background probably won't work, because
if a PMDA install script is run based on a .NeedInstall marker file (ditto
for Remove and .NeedRemove) it may cause the rc script to be called (indeed
a recursive call) which may trigger the pmda_setup logic again ... we'll
need a global marker in the filesystem (or possibly better, in the
environment) to indicate that a pmda_setup is running.

Martins, could you please try the attached patch and let me know if this
resolves the issue.

When Nathan is back, it would be interesting to know what was the original
motivation for running pmda_setup in the background.

Attachment: rc_pmcd.patch
Description: Binary data

<Prev in Thread] Current Thread [Next in Thread>