On Fri, Nov 03, 2006 at 08:51:03PM +0100, beck wrote: > Package: ntpdate > Version: 1:4.2.2.p4+dfsg-1 > Severity: normal > > > Hi, > > it appears that the new way ntpdate-debian is called from if-up.d (starting > it as a background process to prevent delays during boot) can lead to a > race with hwclock.sh which is called later from rcS. In my case, ntpdate > was seemingly started after the interface went up and ran a while in the > background. In the meantime, hwclock.sh corrected the clock according to > CMOS clock information. At this point, the clock is correct, but ntpdate > is still not completed. When it finally completes, it corrects the clock > by another hour, resulting in a wrong clock. The unsatisfactory result is > that though I have a correct CMOS clock, working NTP servers and I am > running both ntpdate and a local NTP server, I end up with the wrong > time. Due to the large offset, ntpd will not fix the clock, either.
ntpdate should never adjust the clock wrong by an hour, it should set it correct. I think your problem is that hwclock is started after ntpdate. > My CMOS clock is running in local time (intentionally) which is CET. Do you know about #342887 and all it's merged bugs, which is supposed to be fixed in util-linux 2.12r-13 just a few days ago? It had a problem with time not in UTC. It seems to have moved to S8 according to the changelog, and I believe that should fix your problem. Can you please chech that it works with the new util-linux? I intend to reassign this to util-linux and close it. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
