The ntpd leap status is not reset after inserting a leap second

Environment

• Red Hat Enterprise Linux 6 [ntp client and server ]
• Red Hat Enterprise Linux 7 [ntp client and server ]
• NTP server configured using ntp version 4.2.6

Issue

• The ntpd leap status is not reset after inserting a leap second.
• After inserting a leap second the ntpd server continues to announce an upcoming leap second.
• Why is the leap flag(leap=01) still observed even after June 30 2015 leap second insertion in Red Hat Enterprise Linux ?

Resolution

Solution

For RHEL6, update to version ntp-4.2.6p5-10.el6 or later, refer to RHSA-2016-0780
For RHEL7, update to version ntp-4.2.6p5-25.el7 or later, refer to RHSA-2016-2583

Workaround

• Restart the ntpd service by executing one of the following commands, depending on version:

  • RHEL 6: service ntpd restart
  • RHEL 7: systemctl restart ntpd

Note
1. Restart the ntp service on the server if it is stuck with leap=01, as seen in the Diagnostic Steps of this solution. This restart will only be helpful when the upstream NTP server is no longer announcing the leap event, and only if the ntp server managed by the organization is stuck with leap=01.

2. If the NTP client/server is configured to use NTP servers which are not controlled by the organization, then the ntp client/server should be reconfigured to use different NTP server or the ntp client should be configured to use slew mode atleast 24 hour prior the event. Restarting the ntp client will only help if the NTP server is no longer announcing the leap event.

Root Cause

• 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.

• This issue is being tracked in This content is not included.RHBZ 1242553.

Here is a table showing how different ntp versions handle the leap second status

• As per the above table, if a ntp client based on 4.2.6 version receives the leap second notification, then it can set the kernel leap second flag after July 30. This may cause the kernel to insert the leap second again on July 31 23.59.60 UTC. ntp clients based on 4.2.2/4.2.4 will set the kernel leap flag only on June 30 or December 31. The kernel leap flag will only be set by the ntp client based on 4.2.6 if the majority of the NTP servers mentioned in the ntp.conf announce and agree on the leap second announcement. ntp clients based on 4.2.2/4.2.4 can set the kernel leap flag when atleast one of the upstream NTP sources makes the announcement

Diagnostic Steps

For Clients:

To determine if the ntpd server is announcing a leap second execute the following command:

ntpq -c as -c 'mrv &1 &999 leap,srcadr,stratum'

Example ntpq output from the client which shows two upstream server having leap=01

#  ntpq -n -c as -c 'mrv &1 &999 leap,srcadr,stratum'

ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 58031  9649   yes   yes  none  sys.peer  leap_armed  4
  2 58032  9324   yes   yes  none   outlyer   reachable  2
  3 58033  9424   yes   yes  none candidate   reachable  2
  4 58034  9424   yes   yes  none candidate   reachable  2
srcadr=200.59.16.50, leap=01, stratum=1
srcadr=66.40.130.103, leap=01, stratum=2
srcadr=173.44.32.10, leap=00, stratum=2
srcadr=208.75.89.4, leap=00, stratum=2

For Servers:

Use the following command to check whether local ntpd is stuck ( serving incorrect leap status to clients)

 ntpq -c 'rv 0 leap'

Example output of the above command

$ ntpq -c 'rv 0 leap'
leap=01

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.