Hi guys,
----- Original Message -----
> On 30/12/14 12:03, Mark Goodwin wrote:
> > > ...
> > most likely pmdaproc on the remote host is running as the pcp user,
> > which doesn't have access to all of the /proc/<pid>/... data for users
> > other than pcp. The proc.nprocs metric is extracted from /proc/stat,
> > which doesn't have such access restrictions (world readable).
>
> And the metrics _will_ be available on the same host as pmcd using -h
> local: (default for most tools, but not pmchart I just discovered)
libpcp_qmc needs some work to resolve this, I think there's an open
BZ for this from Marko, masquerading as a pmdumptext bug.
> because the connection uses a local domain socket and the access control
> rules are relaxed compared to connection to pmcd via an ip socket (like
> a remote pmlogger uses).
The difference with unix(7) sockets is we are able to use the SO_PASSCRED
facility to automatically pass credentials, locally. For remote access a
SASL (and typically NSS/TLS) setup is required which is not on-by-default.
Chandana, re possible memleaks affecting that older pmcd, a few fixes over
the last year or so spring to mind as probably related ...
d1bfabb2 Resolve a pmdalinux memory leak in cpu:node resolution
f08713f6 plug memory leak in /proc/interrupts parsing
b1e94cd4 correct stack blowage during ioctl() for network interface
There are no known pmcd/DSO leaks in more recent pcp versions. Also, one
final option up your sleeve re proc metrics is the pmdaproc(1) -A option.
cheers.
--
Nathan
|