> -----Original Message-----
> From: Frank Ch. Eigler [mailto:fche@xxxxxxxxxx]
> Sent: Wednesday, 17 February 2016 3:48 AM
> To: Lukas Berk <lberk@xxxxxxxxxx>
> Cc: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>; pcp@xxxxxxxxxxx
> Subject: Re: Derived metric issues
> ...
> Perhaps we can say it's a best-effort load attempt, and only result
> codes 0...N are to be expected. (Ditch the negative error codes.)
> That gives the author no help as to which derived metrics were in fact
> loaded, but that's OK. She'll find that out soon enough when trying a
> pmLookup* etc.
I checked the code in libpcp ... it was wrong and did not accumulate the
count of loaded definitions correctly when more than one file was processed.
That is now fixed.
I check the QA ... incomplete coverage of the error scenarios we're talking
about here ... qa/969 is new to address this.
In the process I discovered that bad derived metric specifications generate
quite verbose and succinct error messages!
And finally the man page now reads like this ...
Because pmLoadDerivedConfig may process many files, each of which
may
contain many derived metric specifications, it is not possible to pro
‐
vide very specific error status on return. Hence the result
from
pmLoadDerivedConfig will be the number of derived metrics
successfully
loaded from files on the given path. Catastrophic errors such as
not
being able to open one of the files on the given path will cause
an
immediate return with a negative return value that can be passed
to
pmErrStr(3) to obtain the associated error message.
When errors are encountered in the derived metric specifications diag
‐
nostic messages are generated by pmRegisterDerived(3) and
displayed
via pmprintf(3).
I think that should suffice to close this issue.
|