Hi,
Ken McDonell <kenj@xxxxxxxxxxxxxxxx> writes:
[...]
> 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.
Is there any case where, after calling pmLoadDerivedConfig() a
client/user would *expect* there to be zero derived metrics loaded?
In each of the cases mentioned above, we avoid giving an error status
where there are errors with individual or individual sets of derived
metrics when being loaded within a greater set. I think that makes
sense. However, if not a single derived metric is loaded, would it not
make sense to try and give a more descriptive return value?
Perhaps it is simply up to the client author to interpret a return value
of 0 accordingly?
Cheers,
Lukas
|