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.
Bug 1242553 - ntpd doesn't reset system leap status when disarming leap timer
Summary: ntpd doesn't reset system leap status when disarming leap timer
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ntp
Version: 7.1
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Miroslav Lichvar
QA Contact: Jakub Prokes
URL:
Whiteboard:
Depends On:
Blocks: 1203710 1243034 1289025 1295829 1313485
TreeView+ depends on / blocked
 
Reported: 2015-07-13 14:57 UTC by Miroslav Lichvar
Modified: 2019-12-16 04:49 UTC (History)
10 users (show)

Fixed In Version: ntp-4.2.6p5-24.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1243034 (view as bug list)
Environment:
Last Closed: 2016-11-03 19:31:43 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
fix resetting of leap status (489 bytes, patch)
2015-07-23 07:33 UTC, Miroslav Lichvar 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Network Time Protocol 2246 0 None None None 2019-03-14 11:38:03 UTC
Red Hat Knowledge Base (Solution) 1530053 0 None None None 2016-11-14 15:28:17 UTC
Red Hat Product Errata RHSA-2016:2583 0 normal SHIPPED_LIVE Moderate: ntp security and bug fix update 2016-11-03 12:08:36 UTC

Description Miroslav 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:
Comment 1 Miroslav Lichvar 2015-07-14 12:52:12 UTC 
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.
Comment 4 Miroslav Lichvar 2015-07-23 07:33:29 UTC 
Created attachment 1055196 [details]
fix resetting of leap status
Comment 10 errata-xmlrpc 2016-11-03 19:31:43 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.