----- Original Message -----
> 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.
Ah OK, good to know.
> /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
> [ ... ]
Missing the statfs calls here...?
> 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
>
If no luck there, could you add diagnostics to the pmdalinux code which
pushes the EACCESS errno back out (quoted above) - to see what fs->path
was at time of failure.
cheers.
--
Nathan
|