Description of Problem: A server is able to get a time sync from a remote NTP server when using the stock kernel (2.4.18-3). After kernel upgrade to 2.4.18-4 the system no longer syncs to NTP server. Syncs OK on return to old kernel. Version-Release number of selected component (if applicable): ntp-4.1.1-1 kernel-2.4.18-4-i686.rpm How Reproducible: Tried on three systems. Systems with -3 kernel all OK, systems with -4 kernel will not sync. Steps to Reproduce: NTP configuration using following as /etc/ntp.conf >server 203.21.84.4 >driftfile /etc/ntp/drift >authenticate no Actual Results: Expected Results: Additional Information:
Details? Network card in use, log messages from ntpd and the kernel... anything.
I can't reproduce the bug with 2.4.18-4. During test runs, `service ntpd start` properly synchronizes the date to that given by the ntp server.
ntpdate works OK regardless of kernel version. daemon starts OK regardless of kernel version. ability to sync is affected by kernel version. The following example is with 2.4.18-4 where ntpd has failed to sync. #ntpq -c rl status=c011 sync_alarm, sync_unspec, 1 event, event_restart, version="ntpd 4.1.1 Mon Apr 8 06:30:52 EDT 2002 (1)", processor="i686", system="Linux2.4.18-4", leap=11, stratum=16, precision=-16, rootdelay=0.000, rootdispersion=1480.305, peer=0, refid=0.0.0.0, reftime=00000000.00000000 Thu, Feb 7 2036 17:28:16.000, poll=4, clock=c0afed14.8bf950b9 Tue, Jun 11 2002 13:29:24.546, state=1, offset=0.000, frequency=0.000, jitter=0.015, stability=0.000 #service ntpd status ntpd (pid 8721) is running... # service ntpd stop Shutting down ntpd: [ OK ] # grep ^server /etc/ntp.conf server time.esec.com.au # ntpdate time.esec.com.au 11 Jun 13:38:25 ntpdate[10244]: step time server 203.21.84.4 offset 2.302798 sec #service ntpd start Starting ntpd: [ OK ] #ntpstat unsynchronised time server re-starting polling server every 16 s ---------------------------------------------------- For comparison, this is what I expect it to look like if it syncs OK. This is from a 7.3 system with the 2.4.18-3 kernel. #ntpq -c rl status=06a4 leap_none, sync_ntp, 10 events, event_peer/strat_chg, version="ntpd 4.1.1 Mon Apr 8 06:30:52 EDT 2002 (1)", processor="i686", system="Linux2.4.18-3", leap=00, stratum=3, precision=-17, rootdelay=297.768, rootdispersion=202.113, peer=22508, refid=cougar.esec.com.au, reftime=c0afebda.15d50a88 Tue, Jun 11 2002 13:24:10.085, poll=10, clock=c0afefbe.be40b780 Tue, Jun 11 2002 13:40:46.743, state=4, offset=-55.761, frequency=26.500, jitter=131.953, stability=0.180 # ntpstat synchronised to NTP server (203.21.84.4) at stratum 3 time correct to within 164 ms polling server every 1024 s (ntpstat is from http://people.redhat.com/rkeech)
I'm not seeing this on 2.4.18-4 (athlon, smp). Checking elsewhere (and running ntpstat shortly), too. [root@dhcp59-217:~]# uname -a Linux dhcp59-217.rdu.redhat.com 2.4.18-4smp #1 SMP Thu May 2 17:39:13 EDT 2002 i686 unknown [root@dhcp59-217:~]# ntpq -c rl status=0544 leap_none, sync_local_proto, 4 events, event_peer/strat_chg, version="ntpd 4.1.1 Mon Apr 8 06:30:52 EDT 2002 (1)", processor="i686", system="Linux2.4.18-4smp", leap=00, stratum=11, precision=-17, rootdelay=0.000, rootdispersion=10.996, peer=44828, refid=LOCAL(0), reftime=c0b47944.5a3dd54d Fri, Jun 14 2002 10:16:36.352, poll=6, clock=c0b47947.dfe9c886 Fri, Jun 14 2002 10:16:39.874, state=4, offset=0.000, frequency=0.000, jitter=0.011, stability=0.000
I get a 404 (page not found) when attempting to retrieve ntpstat.
Seeing this same behavior on 2 Dell Inspiron 8100 Laptops which both worked fine under 7.2. Upgraded to RH8.0 and RedHat kernel 2.4.18-17.8 (to fix a sound card problem) Both systems will sync via ntpdate however ntpd can not adjust the time. Clocks on both systems drift slow... ntpq -p and ntptrace both indicate the system is *never* in sync...
I can confirm the same behaviour. I'm running 10+ RedHat 7.3 servers here on different pieces of hardware (SGI 1200, IBM x330, IBM x335). It took me several months before I concluded something had to be wrong with the NTP daemons. All clocks were off by anything from 1 to 600 (!) seconds. Versions in use: ntp-4.1.1-1 kernel-2.4.18-4-i686.rpm I've also used ntpstat to diagnose the problem. Same behaviour as mentioned above. Downgrading to the RedHat 7.1 NTP release (ntp-4.0.99k-15) solved it for me.
I've been seeing the same symptoms on 3 Red Hat 8.0 systems with updates (and Ximian Gnome desktop): [root@villiers root]# uname -a Linux villiers.belding.org 2.4.18-19.8.0smp #1 SMP Thu Dec 12 04:36:25 EST 2002 i686 i686 i386 GNU/Linux [root@villiers root]# rpm -q ntp ntp-4.1.1a-9 [root@villiers root]# service ntpd restart Shutting down ntpd: [ OK ] ntpd: Synchronizing with time server: [ OK ] Starting ntpd: [ OK ] [root@villiers root]# ntpq -c rl status=c011 sync_alarm, sync_unspec, 1 event, event_restart, version="ntpd 4.1.1a Sat Aug 31 18:27:29 EDT 2002 (1)", processor="i686", system="Linux2.4.18-19.8.0smp", leap=11, stratum=16, precision=-17, rootdelay=0.000, rootdispersion=4.725, peer=0, refid=0.0.0.0, reftime=00000000.00000000 Thu, Feb 7 2036 1:28:16.000, poll=4, clock=c1d25567.096909ae Fri, Jan 17 2003 5:11:51.036, state=1, offset=0.000, frequency=0.000, jitter=0.008, stability=0.000 [root@villiers root]# ntpstat unsynchronised time server re-starting polling server every 16 s [root@villiers root]# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== fear.ifs.umich. 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00 [root@villiers root]# ntptrace villiers.belding.org: stratum 16, offset 0.000055, synch distance 0.00356 0.0.0.0: *Not Synchronized* [root@villiers root]#
Please ignore my earlier comment; my problems were caused by redhat-config-date, bug 78025, and don't appear to have anything to do with ntpd or the kernel.
*** Bug 88149 has been marked as a duplicate of this bug. ***
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/