Re: [Condor-users] condor_status hostname : why can't I use IP number instead of hostname?

[Steven Timm <timm@xxxxxxxx>]

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
> [...snip...]
> 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......
>
> Thanks,
> Rob.

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.

Steve


> _______________________________________________
> Condor-users mailing list
> To unsubscribe, send a message to condor-users-request@xxxxxxxxxxx with a
> subject: Unsubscribe
> You can also unsubscribe by visiting
> https://lists.cs.wisc.edu/mailman/listinfo/condor-users
>
> The archives can be found at:
> https://lists.cs.wisc.edu/archive/condor-users/

--
------------------------------------------------------------------
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.