Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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 2RHEL 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.
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.
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.
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.