G'day Marko,
Sorry for your pain ... it should not be like this ... 8^)
On 09/02/16 18:43, Marko Myllynen wrote:
Hi,
Please consider the test case below:
...
3) If the config file contains only some garbage like "asd" then
I see errors printed while in pmLoadDerivedConfig but it returns
zero - this looks like an obvious bug
The problem here is that the argument to pmLoadDerivedConfig may be a
file name, a directory name or a PATH-style list of file/directory
names. And each file may contain more than one derived metric definition.
So the concept of an "error" here is a bit tricky ...
- missing file or directory in the PATH-style list ... probably not an
error, should be silently ignored
- file that cannot be accessed during recursive descent ... probably not
an error
- bad metric spec in a file ... again, not sure as there may be other
valid definitions in the same file (consider a commonly used derived
metric file that is expected to work mostly work even if some of the
definitions involve metrics or PMDAs that might not be available in the
current context, especially an archive)
This is why pmLoadDerivedConfig() returns the "will be the number of
derived metrics loaded" (from the man page) .. in your case this would be 0.
4) If the config file contains a valid derived metric definition
then everything works until pmLookupDesc fails. Shouldn't it work
with derived metrics as well?
This is a problem in the test code. Buried at the end of the
pmRegisterDerived(3) man page (not the pmLoadDerivedConfig(3) man page
unfortunately) is this caveat ...
pmRegisterDerived does not apply retrospectively to any open contexts,
so the normal use would be to make all calls to pmRegisterDerived
(possibly via pmLoadDerivedConfig(3)) and then call pmNewContext(3).
Derived metric parsing occurs in two stages:
1. syntactic when pmRegisterDerived or pmLoadDerivedConfig is called.
2. semantic when each new context is created thereafter.
If you reverse the order of your pmLoadDerivedConfig() and
pmNewContext() calls in your test code, the pmLookupDesc() works as
expected.
I'd welcome any suggestions as to how this important piece of
information could be made more visible.
|