On Mon, Jun 29, 2009 at 10:58:00AM +0200, Vincent Lefevre wrote: > Package: ntp > Version: 1:4.2.4p6+dfsg-2 > Severity: normal > > When ntpd starts while Internet connection is not up yet (this happens > when using wifi after the user has logged in), all the servers are > removed, so that ntpd no longer works. For instance, the syslog file > shows: > > Jun 29 09:07:23 xvii ntpd[3868]: ntpd [email protected] Fri Jun 12 15:39:51 > UTC 2009 (1) > Jun 29 09:07:23 xvii ntpd[3869]: precision = 1.000 usec > Jun 29 09:07:23 xvii ntpd[3869]: Listening on interface #0 wildcard, > 0.0.0.0#123 Disabled > Jun 29 09:07:23 xvii ntpd[3869]: Listening on interface #1 wildcard, ::#123 > Disabled > Jun 29 09:07:23 xvii ntpd[3869]: Listening on interface #2 lo, ::1#123 Enabled > Jun 29 09:07:23 xvii ntpd[3869]: Listening on interface #3 lo, 127.0.0.1#123 > Enabled > Jun 29 09:07:23 xvii ntpd[3869]: kernel time sync status 0040 > Jun 29 09:07:23 xvii kernel: [ 31.080545] ADDRCONF(NETDEV_UP): wlan0: link > is not ready > Jun 29 09:07:23 xvii ntpd[3869]: frequency initialized 0.510 PPM from > /var/lib/ntp/ntp.drift > Jun 29 09:07:23 xvii named[3498]: network unreachable resolving > '0.debian.pool.ntp.org/AAAA/IN': 193.0.14.129#53 > Jun 29 09:07:23 xvii named[3498]: network unreachable resolving > '0.debian.pool.ntp.org/A/IN': 193.0.14.129#53
I think your problem is that you have a local named that returns a permanent error to ntpd when it tries to resolv. As far as I know ntpd will behave correctly when it can't reach a nameserver. Kurt -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
