[erlang-questions] {error,timeout} with gethostbyname

Raimo Niskanen raimo+erlang-questions@REDACTED
Tue Sep 29 10:06:47 CEST 2009

On Mon, Sep 28, 2009 at 06:21:30PM +0200, info wrote:
> Ok.
> According to this information, I followed by hand the code (not easy ...) until:
> inet_gethost_native:gethostbyname("my_host",inet) which returns {error,timeout}
> This function calls getit(1,1,"my_host") but I don't know how to simulate it : it calls Pid ! {{self(),Ref}, Req} 
> After I am lost ... there is do_open_port(get_poolsize(),get_extra_args()) ?

Yep. You would probably not want to go further...

inet_gethost_native is a server that keeps a port program written in C,
erts-5.7.1\bin\inet_gethost.exe, source in erts/etc/common/inet_gethost.c
for doing the actual calls to gethostbyname().

inet_gethost_native will compose a query, send it to the port program,
the port program will dispatch it to one of its worker threads,
wait for the answer, reply, and inet_gethost_native presents an answer.

You can, if you run werl not from cygwin, activate a debug console.
1> inet_gethost_native:control({debug_level,99}).
2> inet_gethost_native:gethostbyname("foo").

Command 1> pops up a debug console, here is my content after 2>:
C:\PROGRA~1\ERL57~1.1\ERTS-5~1.1\bin\inet_gethost.exe[452] (DEBUG):debug_level = 99
C:\PROGRA~1\ERL57~1.1\ERTS-5~1.1\bin\inet_gethost.exe[452] (DEBUG):Got data on index 0.
C:\PROGRA~1\ERL57~1.1\ERTS-5~1.1\bin\inet_gethost.exe[452] (DEBUG):Got data from erlang.
C:\PROGRA~1\ERL57~1.1\ERTS-5~1.1\bin\inet_gethost.exe[452] (DEBUG):OPeration == 1.
C:\PROGRA~1\ERL57~1.1\ERTS-5~1.1\bin\inet_gethost.exe[452] (DEBUG):Saved domainname .
C:\PROGRA~1\ERL57~1.1\ERTS-5~1.1\bin\inet_gethost.exe[452] (DEBUG):Created worker[2232] with fd 3822312
C:\PROGRA~1\ERL57~1.1\ERTS-5~1.1\bin\inet_gethost.exe[452] (DEBUG):Saved domainname .
C:\PROGRA~1\ERL57~1.1\ERTS-5~1.1\bin\inet_gethost.exe[2232] (DEBUG):Worker got data on message que.
C:\PROGRA~1\ERL57~1.1\ERTS-5~1.1\bin\inet_gethost.exe[2232] (DEBUG):Worker got request, op = 1, proto = 1, data = foo.
C:\PROGRA~1\ERL57~1.1\ERTS-5~1.1\bin\inet_gethost.exe[2232] (DEBUG):Starting gethostbyname(foo)
C:\PROGRA~1\ERL57~1.1\ERTS-5~1.1\bin\inet_gethost.exe[2232] (DEBUG):gethostbyname OK
C:\PROGRA~1\ERL57~1.1\ERTS-5~1.1\bin\inet_gethost.exe[452] (DEBUG):Got data on index 1.

Number 3 and 2 from the end says gethostbyname(foo) was
called and returned OK. The data is then passed up to
the waiting inet_gethost_native and converted to hostent tuple.

Do you have DNS or other name resolving configured on some other
interface in your machine that may cause lookup failure and timeout?

You can also increase the timeout that inet_gethost_native uses
to wait for an answer, to see if there is a very late answer
after all. inet_db:set_timeout(15000) will give you a timeout
of one minute instead of 8 seconds default. inet_gethost_native
uses 4 times that value in milliseconds as timeout.

> First some words about the history of these dark corners
> of name resolution in Erlang, especially for Windows.
> In the beginning Erlang tried to mimic how Unix OS:es
> does name resolution by parsing files in the same way
> as the OS. This turned out to be very hard to get
> correct for all dialects, and impossible for Windows,
> so the native resolver was introduced and is now
> default for Erlang. It uses the native OS calls
> gethosbyname(), gethostbyaddr(), getipnodebyname()
> getipnodebyaddr(), getaddrinfo(), getnameinfo() et.al
> on different OS:es so Erlang will behave as any other
> application on the OS.
> The building blocks used in the old way are still there,
> inet_hosts, inet_res+inet_dns, and inet_db plus inet_config
> and more does a lot of strange things to both be backwards
> compatible and still useful...
> OK, then, let's move on.
> On Sun, Sep 27, 2009 at 07:26:49PM +0200, info wrote:
> > Please find a lot of questions in order to undertand the process for understanding how erlang is working with the DNS data.
> > 
> > When erl is starting, the inet_db is built: correct ?
> Yes.
> > When erl stops, the inet_db is destroyed: correct ?
> Well of course; it is in memory only, and it is not written anywhere.
> > Q: from which information does erl build this db ? from the DNS data ? if yes, which file or database or other source ?
> For short name distribution mode and no distribution mode,
> almost nothing is initialized.  inet:gethostname() is
> called, which calls the OS function gethostname().
> If it returns a FQDN, the domain is taken from that.
> The lookup method is set to 'native'.
> Then a check is made; if the hostname can not be
> looked up through the 'native' lookup method:
>    Add 'file' as a lookup method to use after 'native'.
>    If the domain is not set; add as an
>       address of the hostname to the 'file' method.
>    If the domain is set; try to look up the FQDN
>    through the 'native' lookup method, if that succeedes;
>       add the resolved IP address and aliases to the 'file' method.
>    If the FQDN lookup fails, add as above.
> This fixup of the 'host' method is done to ensure
> that the own hostname can be looked up.
> For long name distribution mode (windows), load configuration from
> windows registry:
> \hklm\system\CurrentControlSet\Services\TcpIp\Parameters\
> varibles:
> DataBasePath, Domain, DhcpDomain, EnableDNS, NameServer and SearchList.
> The DataBasePath is used to read a Unix style "hosts" file.
> There are more variables that should be read, I guess, 
> for example DhcpNameServer.
> After this the same check as for short name mode is done,
> to maybe patch in the 'file' lookup.
> > Q:which module in erlang does that ?
> inet_config through inet_db.
> > Q:is it possible to "follow" it ? 
> Er,... what do you mean "follow".
> > Q:In my case  inet_db doesn't contain the domain name: normal ?
> Since gethostname() on Windows apparently returns the short
> hostname, it is normal.
> > Q:With the native option, which default information I should find in this db ?
> As above. With the -sname or no name option, you should only
> get 'hostname' initialized. With the -name option you should
> get more, probably res_domain maybe res_search, if this data
> is in the registry.
> > You suggested this workaround:
> >  inet_db:add_ns({127,0,0,1}).
> >  inet_db:set_domain("my_domain.local").
> >  inet_db:add_search("my_domain.local").
> >  inet_db:set_lookup([file,dns]).
> > Q:Does it mean that this information are missing in my inet_db ?
> > *******
> > Correct:
> > inet:gethostbyname("my_host").
> > {ok,{hostent,"my_host",[],inet,4,[{127,0,0,1}]}}
> Well, since 'native' lookup is supposed to work, not really,
> but yes... for 'dns' lookup it is missing. In the best of
> worlds this could be read from the registry, but on neither
> of my (Windows 2003, Windows XP) machines is the nameserver
> in the registry...
> Oh, and you got the wrong answer there, the lookup order
> should probably be [dns,file] (my mistake). You got the
> loopback address from the 'file' method instead of
> the external IP address from the 'dns' method.
> Does inet:gethostbyname("www.google.com") work with
> this configuration?
> > 
> > In fact I try to use erlang in order to find what is wrong in my DNS data. There are too much info on google about name resolution ...
> It appears DNS is working for you as both nslookup and
> a sufficiently configured inet_res can look up names
> through DNS. It is some other part of the name server
> in your OS configuration that fails.
> Have you looked at this:
> http://support.microsoft.com/kb/323380
> esp. "How to Configure Forwarders".
> ...or...
> I just looked at my 2003 server, anid under Start - > My Computer
> (right click) - > Properties [Computer Name] there is a
> "Full computer name:" and a "Domain:" configured.
> Under Start - > Control Panel - > Network Connections - >
> Local Area Connection (right click) - > Status,
> Properties, Internet Protocol (TCP/IP), Properties,
> I have set which DNS servers to use. This might
> be what makes native lookup work for me.
> :
> -- 
> / Raimo Niskanen, Erlang/OTP, Ericsson AB


/ Raimo Niskanen, Erlang/OTP, Ericsson AB

More information about the erlang-questions mailing list