Hmm ... the real problem was in ReplacePmnsSubtree where the trap and
signal handling was fatally broken ... but needed a stale lock file to
expose the problem. Which explains the "works for me" syndrome.
I have a patch for this, but it is on the tail end of the monster
PMDA_INTERFACE_4 (dynamic subtree in the PMNS) patch that is about to be
committed to my oss.sgi.com tree.
On Fri, 2009-09-25 at 09:10 +1000, Nathan Scott wrote:
> ----- "Ken McDonell" <kenj@xxxxxxxxxxxxxxxx> wrote:
>
> > Are tests 647 and 648 expected to be passing with the current 2.9.2
> > pcp code?
>
> 647 should pass, 648 is notrun atm (has some complex indom handling
> tests that aren't implemented in current pmdammv - on my todo list).
>
> > [Fri Sep 25 06:51:33] pmdammv(30314) Info: pmdammv: 7 metrics and 2
> > indoms after reload
> > /usr/share/pcp/lib/ReplacePmnsSubtree: 1: 1: not found
>
> This'd be your root cause.
>
> > $ pminfo -f mmv
> > mmv.reload: pmLookupDesc: Try again. Information not currently available
>
> Just checked, and it works for me. There is some conditional code in MMV
> PMDA - see HAVE_MKSTEMP in write_pmnsfile() - perhaps you're going through
> the alternate path to me (that MACRO is set on my dev box)?
>
> cheers.
>
|