Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 66417 - NTP will not sync with kernel 2.4.18-4
NTP will not sync with kernel 2.4.18-4
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
: 88149 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2002-06-10 02:32 EDT by Richard Keech
Modified: 2013-07-03 09:05 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-30 11:39:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Richard Keech 2002-06-10 02:32:23 EDT
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):



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

>driftfile /etc/ntp/drift
>authenticate no

Actual Results:

Expected Results:

Additional Information:
Comment 1 Ben LaHaise 2002-06-10 12:41:23 EDT
Details?  Network card in use, log messages from ntpd and the kernel... anything.
Comment 2 Brian Brock 2002-06-10 18:59:09 EDT
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.
Comment 3 Richard Keech 2002-06-10 23:44:29 EDT
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@1.786 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=, 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 offset 2.302798 sec

#service ntpd start
Starting ntpd:                                             [  OK  ]

  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@1.786 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,
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 ( at stratum 3 
   time correct to within 164 ms
   polling server every 1024 s

(ntpstat is from http://people.redhat.com/rkeech)
Comment 4 Brian Brock 2002-06-14 10:21:31 EDT
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@1.786 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,
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
Comment 5 Brian Brock 2002-06-14 10:23:56 EDT
I get a 404 (page not found) when attempting to retrieve ntpstat.
Comment 6 Need Real Name 2002-10-28 14:35:35 EST
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...
Comment 7 Matthijs van der Klip 2002-11-28 09:26:47 EST
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:


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 
Comment 8 Theodore C. Belding 2003-01-17 05:25:02 EST
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
[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@1.791 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=, 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
  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.         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        *Not Synchronized*
[root@villiers root]#
Comment 9 Theodore C. Belding 2003-01-17 07:06:40 EST
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.
Comment 10 Brent Fox 2003-05-21 22:40:07 EDT
*** Bug 88149 has been marked as a duplicate of this bug. ***
Comment 11 Bugzilla owner 2004-09-30 11:39:40 EDT
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

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/

Note You need to log in before you can comment on or make changes to this bug.