On 07/16/2013 08:08 PM, Nathan Scott wrote:
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).
On my box /etc/mtab is a symlink to /proc/mounts.
/proc/mounts is a symlink to /proc/self/mounts
/proc is globally searchable, as is /proc/self
/proc/self/mounts has perms 444 brolley brolley which makes is globally
readable.
> sudo strace -u pcp df
[ ... ]
open("/etc/mtab", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f878963f000
read(3, "rootfs / rootfs rw 0 0\nproc /pro"..., 1024) = 1024
read(3, "/cgroup/memory cgroup rw,nosuid,"..., 1024) = 1024
read(3, "e-daemon /run/user/brolley/gvfs "..., 1024) = 311
read(3, "", 1024) = 0
close(3) = 0
|