TAI offset is incorrect during the leap second

Solution Unverified - Updated

Environment

  • Red Hat Enterprise Linux 6
  • Applications using TAI offset (specifically the tai field in the timex struct) on a system synchronized by NTP or PTP). This setting is not set system-wide, instead an application can make adjtimex() system calls to obtain the offset between TAI and UTC, which is where this issue exists.

Issue

  • TAI offset is incorrect during the leap second.
  • When repeating a UTC time value during a leap second (when the UTC time should be 23:59:60), the TAI timescale should not stop. The kernel NTP code increments the TAI offset one second too late.

Resolution

  • RHEL6:

    • RHEL6.2.z: This issue has been fixed in kernel-2.6.32-220.62.1.el6 (released with RHBA-2015-0914) and later.
    • RHEL6.3.z: This issue was addressed after the end of EUS support for RHEL 6.3. No Z stream fix is available for RHEL 6.3 please update to a more recent kernel errata mentioned in this section instead.
    • RHEL6.4.z: This issue has been fixed in kernel-2.6.32-358.59.1.el6 (released with RHSA-2015-0803) and later.
    • RHEL6.5.z: This issue has been fixed in kernel-2.6.32-431.56.1.el6 (released with RHBA-2015-1017) and later.
    • RHEL6.6.z: This issue has been fixed in kernel-2.6.32-504.23.4.el6 (released with RHSA-2015-1081) and later.
    • RHEL6.7GA and later: These releases already include the fix.
    • Red Hat investigated the fix for this issue under internal This content is not included.BZ 1199134.
  • This bug does not affect RHEL4 or RHEL5; the TAI is just not implemented at those versions. RHEL7 also does not affected, it already includes the fix.

Root Cause

  • Only systems with usable TAI offset value are affected by the issue described in this kbase. With default NTP or PTP settings, the command ntptime returns "TAI offset 0". Only if the system is configured intentionally to return TAI offsets (so ntptime returns a TAI offset different from 0), also the kernel issue described in this KCS is relevant for the system. Please refer to the Diagnostic Steps section for details.

  • During the leap second the TAI offset is incorrect. Assuming that a transition from a TAI offset 0 to 1 would happen in June 2018, the following example shows the TAI offset values with, and without the kernel bugfix. Although TAI offsets 0 and 1 were used here in this output from verifying the patch, these are not valid TAI offsets. Valid TAI offsets are bigger or equal to "10".

    • Before the patch has been applied:

      Wed Jun 27 07:59:57 2018 +     46 us (0)        TIME_INS
      Wed Jun 27 07:59:57 2018 + 500086 us (0)        TIME_INS
      Wed Jun 27 07:59:58 2018 +    130 us (0)        TIME_INS
      Wed Jun 27 07:59:58 2018 + 500194 us (0)        TIME_INS
      Wed Jun 27 07:59:59 2018 +    234 us (0)        TIME_INS
      Wed Jun 27 07:59:59 2018 + 500278 us (0)        TIME_INS
      Wed Jun 27 08:00:00 2018 +    325 us (0)        TIME_INS
      Wed Jun 27 07:59:59 2018 + 500381 us (0)        TIME_OOP
      Wed Jun 27 08:00:00 2018 +    425 us (0)        TIME_OOP
      Wed Jun 27 08:00:00 2018 + 500477 us (1)        TIME_WAIT
      Wed Jun 27 08:00:01 2018 +    523 us (1)        TIME_WAIT
      Wed Jun 27 08:00:01 2018 + 500588 us (1)        TIME_WAIT
      Wed Jun 27 08:00:02 2018 +    629 us (1)        TIME_WAIT
      
    • After the patch has been applied:

      Sun Mar  8 19:59:57 2015 +    190 us (0)        TIME_INS
      Sun Mar  8 19:59:57 2015 + 500395 us (0)        TIME_INS
      Sun Mar  8 19:59:58 2015 +    604 us (0)        TIME_INS
      Sun Mar  8 19:59:58 2015 + 500808 us (0)        TIME_INS
      Sun Mar  8 19:59:59 2015 +   1011 us (0)        TIME_INS
      Sun Mar  8 19:59:59 2015 + 501219 us (0)        TIME_INS
      Sun Mar  8 19:59:59 2015 +   5731 us (1)        TIME_OOP
      Sun Mar  8 19:59:59 2015 + 505935 us (1)        TIME_OOP
      Sun Mar  8 20:00:00 2015 +   6136 us (1)        TIME_WAIT
      Sun Mar  8 20:00:00 2015 + 506345 us (1)        TIME_WAIT
      Sun Mar  8 20:00:01 2015 +   6551 us (1)        TIME_WAIT
      Sun Mar  8 20:00:01 2015 + 506678 us (1)        TIME_WAIT
      Sun Mar  8 20:00:02 2015 +   6881 us (1)        TIME_WAIT
      

Diagnostic Steps

Q: If my application needs to use TAI offset, how can I verify that my system is configured to return TAI offsets?

A: Please refer to the following details.

The following output from the ntptime command shows an offset of 0, meaning that the system has not been configured to return TAI offsets. As seen below "TAI offset 0" is shown, if TAI offset is configured the TAI offset should be bigger than 10.

[root@rhel7u2a ~]# ntptime 
ntp_gettime() returns code 0 (OK)
  time dbb00e1c.d8fe68d4  Tue, Oct 18 2016  4:57:32.847, (.847632062),
  maximum error 8285518 us, estimated error 1100 us, TAI offset 0  <-- offset is 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset -357.432 us, frequency -0.018 ppm, interval 1 s,
  maximum error 8285518 us, estimated error 1100 us,
  status 0x2001 (PLL,NANO),
  time constant 6, precision 0.001 us, tolerance 500 ppm,
[root@rhel7u2a ~]# 

An intentionally configured system could return this:

[root@rhel6u8a ~]# ntptime 
ntp_gettime() returns code 0 (OK)
  time dbb0384b.48064a84  Tue, Oct 18 2016  7:57:31.281, (.281346999),
  maximum error 208633 us, estimated error 10415 us, TAI offset 36  <-- proper offset returned
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 567.482 us, frequency -19.185 ppm, interval 1 s,
  maximum error 208633 us, estimated error 10415 us,
  status 0x2001 (PLL,NANO),
  time constant 6, precision 0.001 us, tolerance 500 ppm,
[root@rhel6u8a ~]# 

Q: How can I configure my system to return TAI offsets?

A: Please refer to the following details.

KCS How to simulate ntp leap second has details on setting the option leapfile in /etc/ntp.conf and using a leapfile. Please note that if you have a valid leapfile ntpd will not return a valid TAI offset immediately after ntpd being started or restarted. It should return a valid TAI offset after some period of time has passed, e.g. 30 minutes.

Q: How can I find out if my application is using TAI offsets?

A: Multiple ways can be considered.

The system is providing informations via adjtimex() system calls, whether they are used or not by applications. Possible ways to investigate if an application uses TAI offsets:

  • contact the application vendor about this
  • monitor the system i.e. with systemtap or perf, to see if adjtimex() calls are done asking for TAI offset.
  • inspect the applications sourcecode
SBR
Components
Category

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.