From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20030102 Description of problem: My system generally gains two minutes in a week period. This system has been running non-stop for two weeks now, and was four minutes fast. I have configured NTP (using redhat-config-date) so that it would query the time server for updates to keep the clock syncronized. I have noticed that it had not queried at all during the two week period. Upon running redhat-config-date again, it manually checked the time server and then corrected the time drift. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. see description Actual Results: Clock drifts fast... Expected Results: Clock should stay in sync with nightly queries to the time server. Additional info: $ rpm -q ntp ntp-4.1.1a-9
what does ntpdc say? # /usr/sbin/ntpdc ntpdc> peers remote local st poll reach delay offset disp ======================================================================= ....
$ /usr/sbin/ntpdc ntpdc> peers remote local st poll reach delay offset disp ======================================================================= =time.nist.gov 5.0.0.0 16 512 0 0.00000 0.000000 0.00000
so it does not connect... your /etc/ntp.conf should look like: restrict default ignore restrict 192.43.244.18 mask 255.255.255.255 nomodify notrap noquery restrict 127.0.0.1 driftfile /etc/ntp/drift broadcastdelay 0.008 authenticate yes keys /etc/ntp/keys server 192.43.244.18
Okay - then perhaps this bug needs to be Component == redhat-config-date. When I configured ntp at installation, I expected it to query the server once in a while. This default configuration apparently does not query the server due to an initial configuration issue. The period by which an update can be made should be configurable by redhat-config-date.