[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Condor-users] condor_status hostname : why can't I use IP number instead of hostname?
- Date: Thu, 23 Jul 2009 17:36:05 -0700 (PDT)
- From: Rob <spamrefuse@xxxxxxxxx>
- Subject: Re: [Condor-users] condor_status hostname : why can't I use IP number instead of hostname?
Thank you Matthew and Ian for your reflections on my problem
with condor_status and its hostname resolution.
First of all, the multi-core and single-core PCs are configured in
exactly the same way:
Host Name.... : pm<number>
Primary Dns Suffix...:
Node Type...: Unknown
IP Routing Enabled...: No
WINS Proxy Enabled....: No
So if one is misconfigured, then all are ;).
Also, if I omit the "slot1@" in the condor_status command,
I get same error for both single- and multi-core PCs:
$ condor_status pm37
unknown host pm37
Hostname resolution is the problem with all the PCs; it's the magic
of the @-sign that saves me with multi-core machines.
Hence, I can "trick" condor_status by explicitly use "slot<n>@hostname"
to avoid the hostname resolution problem; but at present you can't do
that with single-core PCs (unless Condor will be modified/augmented with
a "slot@" construct for single-core PCs).
This inconsistency is nagging me and it's very annoying.
The following indeed shows a bit what's going on:
$ env _CONDOR_TOOL_DEBUG=D_ALL condor_status -debug pm37 2>&1
Trying to initialize local IP address (after reading config)
NETWORK_INTERFACE not in config file, using existing value
Config 'FILESYSTEM_DOMAIN': no prefix ==> '$(FULL_HOSTNAME)'
Config 'UID_DOMAIN': no prefix ==> '$(FULL_HOSTNAME)'
ABORT_ON_EXCEPTION is undefined, using default value of False
Config 'TOOL_DEBUG': no prefix ==> 'D_ALL'
Finding proper daemon name for "pm37"
Daemon name contains no '@', treating as a regular hostname
Trying to find full hostname for "pm37"
gethostbyname() failed: Success (errno: 0)
Failed to construct daemon name, returning NULL
condor_status: unknown host pm37
Notice the 8th line about the '@' sign; that's where the magic happens!
If I use "slot1@pm37", this line changes to:
"Daemon name has an '@', we'll leave it alone"
and I get the appropriate results from condor_status!
Obviously "nslookup pm37" tells me: "** server can't find pm37: NXDOMAIN"
OK, I now understand a little bit more what this problem is about.
Then the key question remains:
Is there a way I can tell condor_status to always treat a hostname AS IF
it had an @-sign in it, so that it 'will leave the hostname alone'?
That seems to be the only option to make it work for me with single-core PCs......