On Fri, Dec 18, 2009 at 11:40:15AM -0800, Carl Mascott wrote: > Subject: Race condition between ntp and NetworkManager at entry to runlevel 2 > Package: ntp > Version: 1:4.2.4p4+dfsg-8lenny3 > Severity: important > > *** Please type your report below this line *** > Related bug: 535049 > Symptom: On some startups ntpq -p reports "No association ID's...". > On other startups ntpq -p reports servers & status normally. > I.E., problem is intermittent. > Cause: When ntpq -p reports "No association ID's..." it is because > NetworkManager has not yet brought up the network interface > (eth0 for me) when ntpd is trying to resolve server IP > addresses. If ntpd gives up on resolving addresses at > this point it will never try again later. > Effect: ntpd does not provide time unless restarted manually. > Scope: The symptom I see is a problem with ntp. The underlying > cause could affect other network services as well. > Non-solution: Reorder startup scripts in /etc/rc2.d. > Correct solution: ??
I have no idea why ntpd is saying that resolving failed. But that means it got a permanent error resolving from somewhere. I have no idea how your configuration is set up, but I never get such permanent error. I can perfectly bring up my wireless after some time, and ntpd will pick up the servers after some time. Note that it doesn't directly get them when the network gets up, but it does get them. Anyway, the current ntp init script has this in it: # Required-Start: $network I have no idea how that interacts with network manager, but I would expect atleast some basic things to work. Do you know what's in your /etc/resolv.conf before the network is brought up by network manager? Do you have some sort of local nameserver? What does "grep ^hosts /etc/nsswitch.conf" return? What I find weird in your log is: > Dec 18 09:26:08 ganymede ntpd[2741]: signal_no_reset: signal 17 had flags > 4000000 I've never seen that message before. It seems the child sees an old signal halder for SIGCHLD with SA_RESTORER set. (I have no idea why ntpd is logging this.) This is probably unrelated to your problem. > Workaround: Use modified version of etch's /etc/network/if-up.d/ntp > script as follows: There should not be a need to restart ntpd, I think something else is broken. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org