On Sun, Jul 07, 2013 at 02:30:33PM +0200, Thomas Hood wrote:
> Executive summary: The getaddrinfo() returns different values
> depending on the OS and on nsswitch.conf settings, making it
> very difficult to use getaddrinfo() return values to deciding how
> to handle an error.
Thanks for not giving up here. I attempted to reproduce your results
with your attached test program. Here are my results:
========================
Making resolv.conf empty
Results of looking up www.google.com: status = -11, errno = 111
Results of looking up a bogus name: status = -11, errno = 111
Writing nameserver option to resolv.conf
Results of looking up www.google.com: status = 0, errno = 101
Results of looking up a bogus name: status = -2, errno = 101
Making resolv.conf empty
Results of looking up www.google.com: status = -11, errno = 111
Results of looking up a bogus name: status = -11, errno = 111
Writing incorrect nameserver option to resolv.conf
Results of looking up www.google.com: status = -11, errno = 110
Results of looking up a bogus name: status = -11, errno = 110
========================
This is an almost-sid box with libc6 2.17-5. The results are consistent
with my earlier observations.
> Helmut got different results. Is the difference between my machine
> and Helmut's machine attributable to some diff in nsswitch.conf,
> perhaps? I have:
>
> hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
My system above has another variant:
hosts: files gw_name dns
> This is different in two ways. First the status is -11 (EAI_SYSTEM)
> instead of -2 (EAI_NONAME) when no nameserver can be reached.
> Second, there is now a difference between the empty-resolv.conf
> case and the resolv.conf-with-bogus-address case. In the latter
> case errno is 110 (ETIMEDOUT) instead of 111 (ECONNREFUSED).
> This is better.
Indeed. So maybe mdns is to blame here for part of the trouble? Can you
verify that really the last mdns4 entry makes up for the difference?
> I don't get the impression that the handling of return values
> by the various eglibc layers has been well thought out and
> documented; the developers seem to be making changes ad-hoc.
Thanks for the extensive research here. I concur with your observation.
> In any case, because of all these differences and changes we
> won't have a good, stable getaddrinfo() interface to program
> against until Jessie. In the meantime a program that needs to
> distinguish between different causes for a name resolution
> failure will have to do more than just check the status and
> errno from getaddinfo().
In particular one of the more recent bugs set out to return EAI_NONAME
when the network is unavailable. This may be a condition where a lookup
needs to be retried though.
Helmut
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130708062327.ga7...@alf.mars
