Hmmm ... since we need to open a socket to talk to pmcd, and these
sockets are in the AF_INET domain, nothing much will work unless
hostname to IP addr via gethostname() works, which means you're stuck
with localhost -> 127.0.0.1 as your only option.
This means stopping pmlogger doing the localhost -> hostname() mapping,
which probably means another command line argument to pmlogger to not do
the mapping, while maintaining compatibility by doing the mapping in the
default case.
On Thu, 2010-04-08 at 14:53 +1000, Max Matveev wrote:
> 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
|