pcp
[Top] [All Lists]

Re: [pcp] pmlogger_check is fooled by localhost

To: kenj@xxxxxxxxxxxxxxxx
Subject: Re: [pcp] pmlogger_check is fooled by localhost
From: Max Matveev <makc@xxxxxxxxx>
Date: Thu, 8 Apr 2010 14:53:31 +1000
Cc: pcp@xxxxxxxxxxx
In-reply-to: <1270642137.15121.125.camel@xxxxxxxxxxxxxxxx>
References: <19387.53537.727368.123975@xxxxxxxxxxxx> <1270603621.15121.79.camel@xxxxxxxxxxxxxxxx> <19387.65322.68301.468516@xxxxxxxxxxxx> <1270642137.15121.125.camel@xxxxxxxxxxxxxxxx>
On Wed, 07 Apr 2010 22:08:57 +1000, Ken McDonell wrote:

 kenj> Thanks for the detailed explanation Max.
 kenj> I was going down the path of pmlogger conditionally doing the remapping
 kenj> from localhost to whatever gethostname(3) returns, but that gets ugly as
 kenj> sin when one considers what pmlogger_check would need to do to second
 kenj> guess pmlogger's behaviour.

 kenj> So I change my vote ... I think you're original patch suggestion for
 kenj> pmlogger_check and sticking with localhost in the control file is the
 kenj> best line of attack.  Could we please have a comment added in
 kenj> pmlogger_check to explain the rationale?
Um, maybe not - I've changed my mind (again): pcp really like to be able to
resolve the hostname - I've tried running 'pmlogger -h localhost' on
sonya and first thing it tripped is "No route to host 'sonya'" from
pmNewContext which means that simple use of localhost is not going to
cut it. And even if I fix pmlogger to not do that then pmcd gets in a
way because it also likes to be able to resolve the name returned by
gethostname(3).

I've got a patch (git://oss.sgi.com/makc/pcp pmlogger) which with
leaves localhost alone but bakes the "actual" hostname into the
archives but I'm not sure if I'll even need it because it does not
really solve my underlaying problem which is not having the /etc/hosts
entry for host I'm running on.

What I can of worms...

max

<Prev in Thread] Current Thread [Next in Thread>