What do I need to do for leap second insertion in 2015

Solution In Progress - Updated -

Environment

Red Hat Enterprise Linux 7
Red Hat Enterprise Linux 6
Red Hat Enterprise Linux 5
Red Hat Enterprise Linux 4

Issue

What action do I need to do in my system for leap second insertion, on July 30 2015 UTC?

Resolution

The impact by leap second insertion depends on whether you system uses NTP.

Systems with NTP

Leap second is inserted when some conditions are matched.

If your system uses NTP, you should check the followings:

  1. OS version (RHEL4, RHEL5, RHEL6, or RHEL7)
  2. Kernel version (uname -a)
  3. NTP version (rpm -q ntp)
  4. Whether slew mode setting is used (with -x option or using tinker option)

Now you can confirm what action you need in the following Action Matrix.

  • For details about leap second, also refer to https://access.redhat.com/articles/15145.
  • The information written below, such as workaround, is just reference information. Basically, it is recommended to use the latest version.
  • The version listed below is applied only with normal subscriptions. If you use EUS, please contact your technical support representative.

Systems without NTP

By default, leap second is not inserted.

After leap second is inserted, your system has 1 second difference from others, you need to modify your time manually as needed. However, if you update tzdata package to the latest version before leap second is inserted, your system has appropriate time sequence with leap second insertion. Note that, in this case, your timezone should be set to "right/xxx/xxx", instead of "xxx/xxx" (e.g. right/America/New_York). For the reference to modify your timezone, see How to change timezone which handles leap second.

Note: By using a timezone in the right/* directory the clock is changed to TAI from UTC; any applications that expect the time to be in UTC may encounter issues.

Once tzdata setting is completed, you can see "2015-06-30 23:59:60 -/+ time zone offsets" by a command such as below.

For example: In case of America/New_York, you should be able to check "2015-06-30 19:59:60" because America/New_York is UTC - 4.

 # date -d "2015-06-30 19:59:60"
Tue Jun 30 19:59:60 EDT 2015

Using tzdata, there is 23:59:60(UTC -/+ time zone offsets) without time regression. On the other hand, when inserting leap second by a kernel, NTP, and other methods, you have time regression by having 23:59:59 twice such as below.

For example: In case of UTC - 4

:
2015-06-30 19:59:58
2015-06-30 19:59:59
2015-06-30 19:59:59
2015-06-30 20:00:00
:

Action Matrix

OS Kernel version NTP version in slew mode Issue concerned Action taken Notes
RHEL7 all kernel versions (as of 2015/9/7) ntp-4.2.6p5-19.el7_1.1 or later yes currently no concerns No action required Other*8
RHEL7 all kernel versions (as of 2015/9/7) ntp-4.2.6p5-19.el7_1.1 or later no time regression by leap second insertion by kernel            If regression is concerned, consider using slew mode *3 Other*8
RHEL7 all kernel versions (as of 2015/9/7) ntp-4.2.6p5-19.el7_0 or less yes time regression by NTP*1 If regression is concerned, consider updating ntp Other*8
RHEL7 all kernel versions (as of 2015/9/7) ntp-4.2.6p5-19.el7_0 or less no time regression by leap second insertion by kernel            If regression is concerned, consider updating ntp and using slew mode *3 Other*8
RHEL6 2.6.32-279.5.2.el6 or later ntp-4.2.6p5-3.el6_6 or later yes currently no concerns No action required Other*8
RHEL6 2.6.32-279.5.2.el6 or later ntp-4.2.6p5-3.el6_6 or later no time regression by leap second insertion by kernel If regression is concerned, consider using slew mode *3 TAI offset issue4,Other8
RHEL6 2.6.32-279.5.2.el6 or later ntp-4.2.6p5-1.el6 or ntp-4.2.6p5-2.el6_6 yes time regression by NTP*1 If regression is concerned, consider updating ntp Other*8
RHEL6 2.6.32-279.5.2.el6 or later ntp-4.2.6p5-1.el6 or ntp-4.2.6p5-2.el6_6 no time regression by leap second insertion by kernel If regression is concerned, consider updating ntp and using slew mode *3 TAI offset issue4,Other8
RHEL6 2.6.32-279.5.2.el6 or later ntp-4.2.4p8-2.el6 or ntp-4.2.4p8-3.el6 yes currently no concerns No action required Other*8
RHEL6 2.6.32-279.5.2.el6 or later ntp-4.2.4p8-2.el6 or ntp-4.2.4p8-3.el6 no time regression by leap second insertion by kernel If regression is concerned, consider using slew mode *3 TAI offset issue4,Other8
RHEL6 2.6.32-279.5.1.el6 or earlier ntp-4.2.6p5-3.el6_6 or later yes currently no concerns  No action required Kernel updated is recommended,Other*8
RHEL6 2.6.32-279.5.1.el6 or earlier ntp-4.2.6p5-3.el6_6 or later no fatal issue*5, and time regression by leap second insertion by kernel Consider kernel update. If not possible, consider using slew mode Kernel updated is recommended, and TAI offset issue4,Other8
RHEL6 2.6.32-279.5.1.el6 or earlier ntp-4.2.6p5-1.el6 or ntp-4.2.6p5-2.el6_6 yes time regression by NTP*1 If regression is concerned, consider updating ntp Kernel updated is recommended,Other*8
RHEL6 2.6.32-279.5.1.el6 or earlier ntp-4.2.6p5-1.el6 or ntp-4.2.6p5-2.el6_6 no fatal issue*5, and time regression by leap second insertion by kernel Consider kernel update. If not possible, consider using slew mode*3 (with concerns of regression, also consider updating ntp) Kernel updated is recommended, and TAI offset issue4,Other8
RHEL6 2.6.32-279.5.1.el6 or earlier ntp-4.2.4p8-2.el6 or ntp-4.2.4p8-3.el6 yes currently no concerns No action required Kernel updated is recommended,Other*8
RHEL6 2.6.32-279.5.1.el6 or earlier ntp-4.2.4p8-2.el6 or ntp-4.2.4p8-3.el6 no fatal issue*5, and time regression by leap second insertion by kernel Consider kernel update. If not possible, consider using slew mode*3 Kernel updated is recommended, and TAI offset issue4,Other8
RHEL5 2.6.18-164.el5 or later ntp-4.2.2p1-9.el5 or later yes currently no concerns No action required -
RHEL5 2.6.18-164.el5 or later ntp-4.2.2p1-9.el5 or later no time regression by leap second insertion by kernel If regression is concerned, consider using slew mode *3 -
RHEL5 2.6.18-164.el5 or later from ntp-4.2.2p1-5.el5 to ntp-4.2.2p1-8.el5 yes non-slew mode even when slew mode is set, and time regression by leap second insertion by kernel*6 consider updating ntp -
RHEL5 2.6.18-164.el5 or later from ntp-4.2.2p1-5.el5 to ntp-4.2.2p1-8.el5 no time regression by leap second insertion by kernel   If regression is concerned, consider using slew mode *3 -
RHEL5 2.6.18-128.7.1.el5 or earlier ntp-4.2.2p1-9.el5 or later yes currently no concerns     No action required Kernel updated is recommended
RHEL5 2.6.18-128.7.1.el5 or earlier ntp-4.2.2p1-9.el5 or later no fatal issue*7, and time regression by leap second insertion by kernel Consider kernel update. If not possible, consider using slew mode*3 Kernel updated is recommended
RHEL5 2.6.18-128.7.1.el5 or earlier from ntp-4.2.2p1-5.el5 to ntp-4.2.2p1-8.el5 yes non-slew mode even when slew mode is set, and there is a fatal issue by leap second insertion by kernel, and time regression 6 , 7 Consider kernel update. If not possible, consider updating ntp and using slep mode*3 Kernel updated is recommended
RHEL5 2.6.18-128.7.1.el5 or earlier from ntp-4.2.2p1-5.el5 to ntp-4.2.2p1-8.el5 no fatal issue *7, and time regression by leap second insertion by kernel Consider kernel update. If not possible, consider updating ntp and using slep mode*3 Kernel updated is recommended
RHEL4 kernel-2.6.9-89.EL or later all ntp versions yes non-slew mode even when slew mode is set, time regression by leap second insertion by kernel*6 If regression is concerned, consider an action, like without NTP. *2 -
RHEL4 kernel-2.6.9-89.EL or later all ntp versions no time regression by leap second insertion by kernel If regression is concerned, consider an action, like without NTP. *2 -
RHEL4 2.6.9-78.0.22 or earlier all ntp versions yes non-slew mode even when slew mode is set, and there is a fatal issue by leap second insertion by kernel, and time regression 6 , 7     Consider an action such as updating kernel or unusing ntp *2 Kernel updated is recommended
RHEL4 2.6.9-78.0.22 or earlier all ntp versions no fatal issue*7, and time regression by leap second insertion by kernel Consider an action such as updating kernel or unusing ntp *2 Kernel updated is recommended

*1

There is an issue of 1 second insertion by NTP, instead of kernel, in RHEL6 and RHEL7. For details, see https://access.redhat.com/solutions/1379783.

*2

As for a workaround without NTP, refer to Workaround 1 in the following knowledgebase: https://access.redhat.com/articles/199563.

*3

As for a workaround with slew mode, refer to Workaround 2 in the following knowledgebase: https://access.redhat.com/articles/199563.

*4

For RHEL6, there is a wrong handling of TAI offset, but this issue only affects to an application with TAI (international atomic time). For details, see https://access.redhat.com/solutions/1380403.

*5

There is a fatal issue in RHEL6:

*6

For RHEL5 (with lower than ntp-4.2.2p1-9) and RHEL4, there is an issue that leap second insertion by kernel cannot be disabled even though the system is in slew mode (https://bugzilla.redhat.com/show_bug.cgi?id=431729). As a result, the system time has 08:59:59 twice (like when the system is in step mode). Therefore, in RHEL5 with NTP in slew mode, ensure that your system has more than this version. For RHEL4, this issue has not fixed even in the latest version, and there is no schedule to fix it in the future.

*7

There is a fatal issue in RHEL4 and RHEL5:

*8

For RHEL6 and RHEL7, there is a issue that absolute timers fire early.

How to change timezone which handles leap second

RHEL4, RHEL5, and RHEL6
  1. Updata tzdata to the latest version.

    # yum update tzdata 
    
  2. Change ZONE in /etc/sysconfig/clock to "right//” timezone. (if a system is in the "America/New_York" time zone, "right//” is "right/America/New_York")

    ZONE="right/America/New_York"
    
  3. Back up the current /etc/localtime.

    # cp -p /etc/localtime /etc/localtime.bk
    
  4. Overwrite /etc/localtime by /usr/share/zoneinfo/right/America/New_York.

    # cp -p /usr/share/zoneinfo/right/America/New_York  /etc/localtime
    
  5. Check that you can see "2015-06-30 19:59:60" (it is 23:59:60 - 4 because America/New_York is UTC-4) by the following date command. If succeed, tzdata setting is completed.

       # date -d "2015-06-30 19:59:60"
    Tue Jun 30 19:59:60 EDT 2015
    
RHEL7:
  1. Update tzdata to the latest version.

    # yum update tzdata 
    
  2. Check the current timezone.

    # timedatectl 
      Local time: Mon 2015-06-15 08:23:01 EDT
    Universal time: Mon 2015-06-15 12:23:01 UTC
        RTC time: Mon 2015-06-15 12:20:38
        Timezone: America/New_York (EDT, -0400)
     NTP enabled: yes
    NTP synchronized: yes
    RTC in local TZ: no
      DST active: yes
    Last DST change: DST began at
                  Sun 2015-03-08 01:59:59 EST
                  Sun 2015-03-08 03:00:00 EDT
    Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2015-11-01 01:59:59 EDT
                  Sun 2015-11-01 01:00:00 EST
    
  3. Change timezone to right/America/New_York.

    # timedatectl set-timezone right/America/New_York
    
  4. Confirm that timezone is changed.

    # timedatectl
      Local time: Mon 2015-06-15 08:22:16 EDT
    Universal time: Mon 2015-06-15 12:22:16 UTC
        RTC time: Mon 2015-06-15 12:20:18
        Timezone: right/America/New_York (EDT, -0400)
     NTP enabled: yes
    NTP synchronized: yes
    RTC in local TZ: no
      DST active: yes
    Last DST change: DST began at
                  Sun 2015-03-08 01:59:59 EST
                  Sun 2015-03-08 03:00:00 EDT
    Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2015-11-01 01:59:59 EDT
                  Sun 2015-11-01 01:00:00 EST
    
  5. Check that you can see "2015-06-30 19:59:60" (it is 23:59:60 - 4 because America/New_York is UTC-4) by the following date command. If succeed, tzdata setting is completed.

    # date -d "2015-06-30 19:59:60"
    Tue Jun 30 19:59:60 EDT 2015
    

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.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.