Backing up a little ... my analysis was wrong.
On 18/01/16 21:00, Ken McDonell wrote:
...
Looks like a Python wrapper issue ... libpcp and friends get it right it
would appear.
kenj@bozo:~/src/pcp/qa$ pminfo -c /tmp/eek foo
[/tmp/eek:1] Error: pmRegisterDerived(foo, ...) syntax error
rat(disk.dev.read)
^
Error: foo: Unknown metric name
kenj@bozo:~/src/pcp/qa$ cat /tmp/eek
foo = rat(disk.dev.read)
This is NOT a Python wrapper issue and we do NOT need a libpcp API change.
The C code appears to get it "right" because it does not call
pmRegisterDerived(), it calls pmLoadDerivedConfig() ... the error
message from libpcp contains the wrong function name above.
And pmLoadDerivedConfig() does its own reporting above (it is not
pminfo), including this snippet ...
q = pmDerivedErrStr();
if (q != NULL) pmprintf("%s\n", q);
which produces no output in the example above because pmDerivedErrStr()
returns NULL ... sound familiar?
So returning to Marko's original questions ...
> Here pmDerivedErrStr returns nothing. Is this expected or should
> pmDerivedErrStr be improved to return always something understandable
> in case of errors?
To which the answers are NO and YES!
And when I correct the derived metrics parser for this case, ... bingo!
kenj@bozo:~/tmp$ bad.py
PMAPI exception as requested
bad.py: Generic error, already reported above ['@', '(disk.dev.read']
pmDerivedErrStr: Arithmetic operator expected
So I think the way forward is a closer audit of the derived metrics
parser, not libpcp PMAPI changes.
|