----- Original Message -----
> [DATE] pmcd(PID) Error: pmdaFetch: Fetch callback error from metric PMID
> 60.5.9[3]: Permission denied
>
> Domain number 60 there points the boney Finger Of Blame toward the Linux
> kernel PMDA. In particular something-external-to-the-test is requesting
> values for the following metrics...
>
> $ pminfo -m | egrep '60.5.9$|60.5.7$|60.5.1$|60.5.8$'
> filesys.capacity PMID: 60.5.1
> filesys.mountdir PMID: 60.5.7
> filesys.full PMID: 60.5.8
> filesys.blocksize PMID: 60.5.9
One other thing I forgot to check into - why are we getting "Permission
Denied" in the first place?!?
Auditing the pmdalinux code, I believe the only way this can be happening
for these filesys metrics is this snippet of code in the fetch callback:
(src/pmdas/linux/pmda.c line# ~4700)
sbuf = &fs->stats;
if (!(fs->flags & FSF_FETCHED)) {
if (statfs(fs->path, sbuf) < 0)
return -oserror();
fs->flags |= FSF_FETCHED;
}
I bet you have some paths that cannot be accessed using statfs(2) via the
"pcp" user? Even under "normal" conditions - not just during the test.
The list of fs->path entries comes from filesys.c::refresh_filesys() -
its looking over the /proc/mounts entries.
Can you see anything in /proc/mounts that would be causing this? The df
command uses statfs too, but strace there says its using /etc/mtab - I'd
be interested to see if it gets EACCESS on your box? (strace FTW).
cheers.
--
Nathan
|