Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 Description of problem: as daylight savings happened this morning, i checked my system clock and discovered it off again by about 3 minutes. i determined this by going to http://www.worldtimeserver.com/time.asp?locationid=US-CA (which i believe to be fairly accurate - but only to within one minute thanks to http delays, etc). i've been using dateconfig with ntp enabled and pointed at time.nist.gov for updates. ntp is definitely running. however it appears that ntp isn't updating my system clock. although it wasn't applicable, i applied the patch from bug#64329. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: i selected "every time" for reproducibility, but it is difficult to reproduce because the time skew happens so slowly. the system has been running for about 40 or 50 days since the last time i manually updated the clock. i'm guessing it lost about a second a day or so. Expected Results: ntp should update the system clock at least once per day. thus the system clock should be reasonably accurate. Additional info:
Can you attach your /etc/ntp.conf file?
Created attachment 91754 [details] ntp conf as requested this file has been modified several times since filing the bug. dateconfig still fails to update the system clock. i've been running ntpdate from cron, which has been a bit more successful.
Hmm...the file looks ok to me. I really have no idea why this would happen. ntp works fine for all of us here. I'm not sure what to do. :( What is the contents of the /etc/ntp/step-tickers file?
/etc/ntp/step-tickers is a zero-length file. what's really disturbing about this issue is my system clock is now losing as much as 5 minutes a day. this started happening after i upgraded my kernel to 2.4.18-27.7.x,,,
Hmm...I'm becoming convinced that this problem has nothing to do with dateconfig. After doing a quick Bugzilla query, I ran across bug #66417. This sounds almost identical to your problem. I think this report is a duplicate of that bug. *** This bug has been marked as a duplicate of 66417 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.