pcp
[Top] [All Lists]

Re: [pcp] Hotproc fixes

To: pcp@xxxxxxxxxxx
Subject: Re: [pcp] Hotproc fixes
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Wed, 29 Apr 2015 08:56:17 +1000
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <553FE1BC.4070309@xxxxxxxxxxx>
References: <5536A934.8040002@xxxxxxxxxxx> <5537A154.2090803@xxxxxxxxxx> <5537A3F3.5060204@xxxxxxxxxxx> <233739221.5258413.1429764654377.JavaMail.zimbra@xxxxxxxxxx> <55392BAB.3060101@xxxxxxxxxxx> <806884984.5885784.1429839438565.JavaMail.zimbra@xxxxxxxxxx> <553FE1BC.4070309@xxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
On 29/04/15 05:38, Martins Innus wrote:

...   In the course of this,
I need an error I can use when someone feeds pmstore a bad config.  The
best I could find is PM_ERR_CONV which seems to be used elsewhere, is
that correct?

PM_ERR_CONV is probably the closest error code, although this is most frequently encountered in bad pmExtractValue() calls.

Other alternatives might be PM_ERR_GENERIC (depending on what options you have for reporting the error, e.g. to the PMDA log file), else petition for a new error code by proposing a new macro PM_ERR_FOO and suitable text to be associated with it via pmErrStr().

The latter course of action is OK in cases where none of the existing errors provide a "reasonable" semantic match for the error in question, and is how the error codes have grown over time (about 25% of the current PM_ERR_* macros did not exist in PCP 1.0).

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