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.
DescriptionMiroslav Lichvar
2015-07-13 14:57:06 UTC
Description of problem:
When the system leap status is set in the last day of the month to insert/delete a leap second and the upstream NTP sources later in that day fail to reach majority on the leap second, the leap second timer will be disarmed, but the system leap status will not be reset and the leap second will still be announced to NTP clients.
If not using the -x option, the kernel will step the clock back by one second at midnight even when the sources no longer agree there is a leap second in that day. ntpd will keep setting the kernel leap status and the next day the clock will be stepped again. This incorrect step will be corrected later by forward step, which will finally reset the system status to the normal non-leap value.
If using the -x option, the ntpd instance will continue to announce the leap second to its clients until the service is restarted and the clients may apply it every day/month/6 months depending on their implementation.
Version-Release number of selected component (if applicable):
ntp-4.2.6p5-20.el7
How reproducible:
always
Steps to Reproduce:
1. configure ntpd with a server that simulates a leap second on the last day of a month
2. wait until ntpq -c rv reports leap=01
3. turn the leap status on the server off
4. monitor ntpq -c rv output
Actual results:
leap not reset to 00
Expected results:
leap reset to 00
Additional info:
Actually, the kernel doesn't seem to apply a new leap second until the TIME_WAIT state is cleared by setting a non-INS/DEL status by adjtimex(), which means that even ntpd not configured with -x that went through the leap second with disarmed leap timer could be stuck in the leap state and report it to its clients forever.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://rhn.redhat.com/errata/RHSA-2016-2583.html