[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?

On Thu, 23 Jul 2009, Rob wrote:

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"
Calling gethostbyname(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......


Alternatively, you could define at least 2 slots even on
the single core PC's and then it will work too.  The number
of slots is user-definable and the name of the startd daemon
probably is too, if you know what you are doing.


Condor-users mailing list
To unsubscribe, send a message to condor-users-request@xxxxxxxxxxx with a
subject: Unsubscribe
You can also unsubscribe by visiting

The archives can be found at:

Steven C. Timm, Ph.D  (630) 840-8525
timm@xxxxxxxx  http://home.fnal.gov/~timm/
Fermilab Computing Division, Scientific Computing Facilities,
Grid Facilities Department, FermiGrid Services Group, Assistant Group Leader.