A leap second is coming
The basic timekeeping standard for almost all of the world's local time zones is called Coordinated Universal Time (UTC). UTC is derived from International Atomic Time (TAI) and Universal Time (UT1), also known as mean solar time because it’s the time it takes for the Earth to rotate once on its axis. Because the rotation of the earth varies a bit over time and is slowly decreasing its mean rotation speed, a deviation occurs between UTC and UT1. When this deviation approached .9 seconds, a leap second is inserted into the UTC time scale, which adjusts the UTC time to actual earth rotation.
Leap seconds correct a discontinuity of civil time. The correction does not increase monotonically but it is stepped by one second. Leap seconds present a challenge to computer system timekeeping because standard UNIX time is defined as a set number of seconds since 00:00:00 UTC on 1 January 1970, but without leap seconds. A system clock cannot recognize 23:59:60 because every minute has only 60 seconds and every day has only 86400 seconds.
To help you avoid downtime during the leap second insertion on December 31, 2016, Red Hat Insights has recently released a set of rules to detect various leap second issues. Check out the rules below.
| Rule | Description | Reference |
|---|---|---|
| System clock changes instantly in leap second event in NTP system with slew mode configured [ntpd_slew_mode] | Previous versions of NTP (ntp-4.2.6p5-1 and greater) incorrectly changed the system clock instantantly during a leap second event, despite configuring ntpd with -x. In certain applications, this could lead to a variety of system clock related problems such as incorrect event sorting or triggering. | Does Red Hat plan to release a ntp package including xleap.patch (Important for slew mode i.e. with -x ntp configuration)? |
| System hangs or has high CPU usage during leap second event in NTP systems [leapsec_system_hard_hang] | NTP systems can hang or encounter high CPU usage when a leap second event occurs. | Systems hang due to leap-second livelock., High CPU usage after inserting leap second |
| System clock inaccurate in leap second event in non-NTP systems following TAI timescale [tzdata_need_upgrade] | In a non-NTP RHEL host following the TAI timescale, one can configure non-NTP RHEL systems to report time corrected for leap seconds by updating the tzdata package to the latest version available and then using appropriate 'right' timezone files. | Leap Second queries related to tzdata |
| Ntpd service continues to announce upcoming leap second to clients following leap second insertion [ntpd_not_reset_leap_status] | The ntpd service does not reset the leap status and continues announcing an upcoming leap second to its clients when finishing a leap second insertion in the NTP server due to a known bug in the NTP package. | The ntpd leap status is not reset after inserting a leap second |
| Chronyd service in leap smear NTP server has ~50% chance of crash when configured with smoothtime directive and 1-second polling interval [leap_smear_chronyd_crash] | When chronyd is configured with the smoothtime directive and the smoothing process is updated with an extremely small offset, it may not be able to select a direction in which the offset needs to be smoothed out due to numerical errors in floating-point operations and this causes an assertion failure. | Chronyd crashes when performing server leap smear |
To see if you have systems affected by these new rules, check out the Stability category here.
About The Author
Red Hat
Expert
995 points
Comments