[Top] [All Lists]

Re: weird error

To: Alan Bailey <abailey@xxxxxxxxxxxxx>
Subject: Re: weird error
From: Ken McDonell <kenmcd@xxxxxxxxxxxxxxxxx>
Date: Fri, 1 Dec 2000 09:00:38 +1100
Cc: pcp@xxxxxxxxxxx
In-reply-to: <Pine.LNX.4.10.10011301317120.8012-100000@xxxxxxxxxxxxxxxxxxx>
Reply-to: kenmcd@xxxxxxx
Sender: owner-pcp@xxxxxxxxxxx
On Thu, 30 Nov 2000, Alan Bailey wrote:

> I don't know if this is a problem with the simple pmda, or with dynamic
> shared objects on linux, or with something I might have done.  But it's
> weird, that's for sure :)
> ...
> That should be enough of a description for a diagnosis.  I apologize if
> this is a simple error or something done wrong on my part.

This is most unlikely to be your problem ... I'm investigating.

Just as an aside, there is a generalized tracing and debugging
mechanism in the PCP applications, libraries and daemons.

Check out the pmdbg man page, or run pmdbg -l

Most commands take a -D option with the argument being a numerical
value of the bit-wise or of some debug flags, or a comma separated list
of the debug flag names (stripped of the leading DBG_TRACE_) in upper
or lower case, e.g.

$ pminfo -D profile,pdu -f simple.color

You can use pmstore and the metric pmcd.control.debug to turn tracing
on/off for pmcd, e.g.

$ pmstore pmcd.control.debug 5

turns on PDU and PROFILE tracing for pmcd, and the diagnostics will
be written to /var/log/pcp/pmcd/pmcd.log

In a case like the one above, seeing the Protocol Data Units (PDUs)
exchanged between pminfo and pmcd would be our first port of call in
debugging the problem, so adding this info to bug reports would be

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