On Sun, Jun 30, 2013 at 12:03:47PM +0200, Thomas Hood wrote: > That resolvconf leaves resolv.conf empty of "nameserver" entries when > no nameservers are available is intentional. The idea is to advertise > only addresses where something is actually listening.
Even though intentional it might be a bad decision to do so for other reasons. > By the way, inconsistent with the aforementioned idea is the fact that > the resolver defaults to using 127.0.0.1 if there are no "nameserver" > lines in resolv.conf. Were you aware of that? I were aware, but only because I triggered this case while debugging ntp. Unfortunately there is a subtle difference. When resolv.conf is empty and 127.0.0.1. does not responds, it is EAI_SYSTEM, but when it is listed and not responding it is EAI_AGAIN. I am therefore suggesting to change resolvconf to make this inconsistency explicit and always list 127.0.0.1 when there is no other name server. It should probably be accompanied with a warning comment, because this case should never occur during normal operation. On Sun, Jun 30, 2013 at 10:40:03PM +0200, Thomas Hood wrote: (slightly reordered) > Helmut Grohne wrote: > > It is true, that ntpd can work around this issue. Still it appears like > > a bad design to treat EAI_SYSTEM as a temporary error. > > Can you explain why you think that? The obvious reason here is that having two error codes to be reacted to in the same way is prone to errors. Forget one? But you already gave an even better reason yourself: > A problem is that getaddrinfo() doesn't distinguish in its return > status between "couldn't reach a nameserver" and "nameserver > says the name doesn't exist". Either way it returns EAI_SYSTEM > with errno=2 (ENOENT). It could result in retrying non-existent domains forever. 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/20130705172846.ga9...@alf.mars
