This forum has been archived. Please start a new discussion on GitHub.

Potential getAddress error with unassigned hostname

I'm seeing a case on Linux where if the hostname is unassigned the communicator can't be constructed and ICE exits out with a DNS exception. I haven't exactly stepped through this in a debugger yet, but it looks like Ice uses gethostname(...) and then getaddrinfo(...) on UNIX to resolve the system to an ipaddress. If a hostname is not assigned then getaddrdinfo fails with an Ice DNS exception thrown.

It is possible to have system without hostname, but still have a valid ipaddress. For example, an ipaddress can be assigned via DHCP, but a hostname may or may not be assigned or the ipaddress may not resolve to a hostname in a DNS server. Wondering if Ice should use gethostbyaddr to find the ipaddress if gettaddrinfo fails.

Regards --Roland


  • I just spent some more time discussing this here and trying to understand it better. It is possible to have an ipaddress without a valid hostname assigned. But I'm not sure that this is Ice's problem to resolve. There doesn't appear to be a nice library invocation to just getaddr. My previous suggestion, using gethostbyaddr was rather silly, since the address isn't known either. So this means that the only way left to get this info is a system call and I don't know which one. Possibly ifconfig option will just return the local address. So this leaves several options:

    1. Ice could try to invoke the system call (not sure which one yet) with the proper options if getaddrinfo fails.

    2. Our application could set Ice.Default.Host if a hostname wasn't supplied or resolved. This could be done in our applications shell command which sets up several other environment variables or within our applications actual code.

    3. dhcp pump needs to be set-up to always assign localhost the dhcp assign address.

    I'm not sure which solution is best.

    Regards --Roland
  • dwayne
    dwayne St. John's, Newfoundland
    Hi Roland,

    What version of Ice are you using? As of Ice 3.0.1 the api you mention is no longer used by the server-side to obtain the hostname. A change was made so that if no hostname is supplied in endpoint configuration, the adapter will now listen on all available interfaces. The list of interfaces is obtained using the ifaddrs() system call. The client side in Ice 3.0.1 still uses the old api if no host is specified in proxy configuration. However, once Ice 3.1 is released it will no longer be used there as well.

    If upgrading to 3.0.1 is not an option, setting Ice.Default.Host will certainly solve your issue.

  • Hi Dwayne, My app uses bi-dir connections and is both a server and client, although it is more of a client since it initiates the outgoing connection. I thought the issue it would be independent, since I believe that the problems occurs very early on in the communicator before any object adapters are created. I'll look a little closer. I'm using Ice 2.1 and was looking at the code in Network.cpp. I'll checkout Ice 3.0.1 to see if it helps.

    Thanks for the quick response --Roland
  • benoit
    benoit Rennes, France
    Hi Roland,

    I believe the DNSException you're seeing is coming from the call to getLostHost(true) which is made in src/Ice/DefaultAndOverrides.cpp when the communicator is initialized. As Dwayne mentioned, Ice 3.0.0 doesn't make this call anymore. If you don't want to upgrade to 3.0.0 now, you could just set Ice.Default.Host to in your client. This shouldn't have any effect on your client as long as the proxies that your client is using contain the host information (specified with "-h") and as long as it doesn't create object adapters with endpoints that don't specify the host information.

    In any case, it would better to set the hostname of the machine to something that can be resolved to an IP address. I believe there's several ways to associate the hostname with the DHCP address on Linux. You can for example configure the DHCP client to update your local DNS server or you could run a small script to update the "/etc/hosts" files after the DHCP client retrieved the address information. You should be able to find more information with "man dhclient".

  • Hi Benoit, Thanks for the additional info and this makes a lot of sense. Looks like I have several solutions.

    Thanks again for the quick response --Roland