Bug 751621

Summary: ntpd does not seem to correctly sync the kernel time: kernel time sync status 2040
Product: Red Hat Enterprise Linux 6 Reporter: Daniel Riek <riek>
Component: ntpAssignee: Miroslav Lichvar <mlichvar>
Status: CLOSED INSUFFICIENT_DATA QA Contact: qe-baseos-daemons
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.1CC: sghosh
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-02-04 16:55:51 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Daniel Riek 2011-11-06 11:42:03 UTC 
This is RHEL 6.1 with ntp-4.2.4p8-2.el6.x86_64 on an IBM x3550 M3.

The ntp config is the default config plus additional local ntp servers.

The log file reports "kernel time sync status 2040" - Which translates to NANO and UNSYNC.

Also ntpdc reports the problem:
[root@kvm000 ~]# ntpdc -c kerninfo
pll offset:           0 s
pll frequency:        0.000 ppm
maximum error:        0.090016 s
estimated error:      1.6e-05 s
status:               2040  unsync nano
pll time constant:    0
precision:            1e-09 s
frequency tolerance:  500 ppm

And ntptime agrees:
[root@kvm000 ~]# ntptime
ntp_gettime() returns code 5 (ERROR)
  time d260f02f.d3c9039c  Sun, Nov  6 2011 12:38:23.827, (.827286475),
  maximum error 107516 us, estimated error 16 us, TAI offset 0
ntp_adjtime() returns code 5 (ERROR)
  modes 0x0 (),
  offset 0.000 us, frequency 0.000 ppm, interval 1 s,
  maximum error 107516 us, estimated error 16 us,
  status 0x2040 (UNSYNC,NANO),
  time constant 0, precision 0.001 us, tolerance 500 ppm,

A workaround is, to rebuild the newest NTP package source from Fedora 15:ntp.x86_64 0:4.2.6p3-4. With the newer NTP and identical configuration, the problem goes away:
[root@kvm000 ~]# rpm -q ntp && ntptime 
ntp-4.2.6p3-4.el6.x86_64
ntp_gettime() returns code 0 (OK)
  time d260f0d3.af4655e4  Sun, Nov  6 2011 12:41:07.684, (.684667799),
  maximum error 33016 us, estimated error 16 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 0.000 us, frequency 0.000 ppm, interval 1 s,
  maximum error 33016 us, estimated error 16 us,
  status 0x2001 (PLL,NANO),
  time constant 3, precision 0.001 us, tolerance 500 ppm,
Comment 2 RHEL Program Management 2011-11-06 12:08:40 UTC 
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.
Comment 3 Miroslav Lichvar 2011-11-07 11:52:53 UTC 
Was ntpd synchronized when ntptime was called? What does "ntpq -pn" print?

Zero offset in the ntptime output indicates it wasn't not synchronized yet. The older ntpd clears UNSYNC on first update, the Fedora ntpd clears it on start.
Comment 4 Daniel Riek 2011-11-08 09:36:09 UTC 
The machines have been running for some time. Here is an example:

[root@host001 ~]# ntpq -pn && ntptime

     remote           refid      st t when poll reach   delay   offset 
jitter
==============================================================================
*10.11.12.13      129.132.2.21     3 u   17   64  377    0.286   
1.871   0.169
 127.127.1.0     .LOCL.           5 l  21h   64    0    0.000    0.000  
0.000

ntp_gettime() returns code 5 (ERROR)
  time d2625fab.bb89e730  Mon, Nov  7 2011 14:46:19.732, (.732573975),
  maximum error 16000000 us, estimated error 16 us, TAI offset 0
ntp_adjtime() returns code 5 (ERROR)
  modes 0x0 (),
  offset 0.000 us, frequency 0.000 ppm, interval 1 s,
  maximum error 16000000 us, estimated error 16 us,
  status 0x2041 (PLL,UNSYNC,NANO),
  time constant 3, precision 0.001 us, tolerance 500 ppm,
Comment 5 Miroslav Lichvar 2011-11-08 13:46:23 UTC 
That's odd.

Do you see any time resets reported by ntpd in syslog? Is this on a real hw or virtual machine? Is it possible something else running on the system is touching the clock? "ntpq -c rv" output might help too.
Comment 6 Miroslav Lichvar 2014-02-04 16:55:51 UTC 
From the available information I don't see what's wrong here. I'm closing this bug.

The current ntp version in RHEL6 is ntp-4.2.6p5, which according to the comment #0 doesn't have the problem. Please reopen if you can still see it and have more information.