-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Let me try to get that bug (and all the others) fixed..
Am Di den 2. Jul 2013 um 14:57 schrieb Kurt Roeckx: > On Tue, Jul 02, 2013 at 03:32:13PM +0200, Thomas Hood wrote: > > On Tue, Jul 2, 2013 at 1:59 PM, Kurt Roeckx <k...@roeckx.be> wrote: > > > > > Do you know NXDOMAIN returns? I think it returns just the same? > > > > > > > > > I don't immediately see how getaddrinfo() alone can be used to tell > > whether or not an actual NXDOMAIN was received. A test with a small > > C program reveals that retval -11 errno 2 is returned both in the > > NXDOMAIN case and in the case where no nameservers could be found. > > And I think that a nameserver not found should never have resulted > in that return value, since it's not a permanent error. Well, Kurt, from the system perspective it is a permanent error (in fact, it is a negative answer, not a permanent error.) nsswitch.conf has "file dns" (usually) for DNS. As /etc/resolv.conf is empty at that stage, it answers the name request only with the knowledge of /etc/hosts. After that, NTP knows that the name does not exist. Then, lexically after NTP, the DNS server (unbound in my case, note that bind9 is lexically before NTP) is started and populate /etc/resolv.conf via resolvconf with proper settings. After that the names could get resolved but NTP will never try again. So a working $named is essential to NTP. As mentioned many times now by different people, $named is a virtual target that optionally depends on running DNS. (If you have no local DNS, usually /etc/resolv.conf gets populated by $network target) So the only correct solution _is_ to add $named to the Required-Start setting! There is no other way that addresses all cases of this problem. And it it the only valid solution. So, please, please, get that $named target into Required-Start. For my part, let Helmut Grohne upload that really small and proper NMU. This bug is now more than 3 years old and many people suffer from it. For the fact that NTP is a essential part in the system in many cases, that serious problem needs to get addressed. > > * Computers are mobile these days and DNS also changes from the > > perspective of those computers. A laptop may connect sometimes > > to a LAN where the domain name ntp.somecorp.private resolves to > > the address of a time server. On other LANs this name does not exist. > > Do you expect the DHCP server on the LAN then to set that ntp > server? Currently this would now result in ntpd getting restarted > by dhcp and should get you a working ntp server. Yes. That script needs to get back to the hook directories for that reason. Generally, the mobile approach is a slightly different problem than the one on a server. For a server, not running NTP might be fatal, for a mobile device it is just a small problem. Regards Klaus - -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <kl...@ethgen.ch> Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQGcBAEBCgAGBQJWeTlLAAoJEKZ8CrGAGfasbG8L/2Es7PShwTmhJfD21iMu5HtC 6aHh2FXIbz3M76GQBDOqp6zrqxqYzN5lD7tHF2bcVpHekkfrefpC4cdtjGgaSR4R gpAv+tIpRAzZ9IE13FXfeHZRW8XzBaYjoTAuAtjFYhAUsd7hwm6NPxShcmoyLGVz a4zO9owtOsYRtlbFwVjS1R/KUDXVFaJxeHf7bYlOpclM37nSbTY3CcmRIytlYuVt FY14x0zmLIlauTr54pkz+Ra7iKnTRScHonOuVsnSzeiUUs2rar3FqPvhZQKleq8T dBhQYa/tYLjWJc3+SITtWkcETQyyceWB8qhMygv69XFL86pYBxDRBWhZN7tHwBk1 REw+HkR8diedafdnpIScqB12f9JCKnV3UJZSvfsz0jU6nXmSl5A/Z9bZvPbxX2uU 5WwUySRq3vMJdufgI0x0rD5gpQ3jak+jZzHWdp+dB26wq/uysZF9Y1V2LiPSKHnw dESvi+4iFBJhOofX85rYMgK9TwhvmbWXhrK/ZwrgbA== =klQE -----END PGP SIGNATURE-----
