Fixes and workaround to avoid issues caused by Leap Second 2015.

SUSE Linux Enterprise Server 10 Service Pack 4 (SLES 10 SP4)
SUSE Linux Enterprise Server 10 Service Pack 3 (SLES 10 SP3)
SUSE Linux Enterprise Server 10 Service Pack 2 (SLES 10 SP2)
SUSE Linux Enterprise Server 10 Service Pack 1 (SLES 10 SP1)

SUSE Linux Enterprise Server 11 Service Pack 4 (SLES 11 SP4)
SUSE Linux Enterprise Server 11 Service Pack 3 (SLES 11 SP3)
SUSE Linux Enterprise Server 11 Service Pack 2 (SLES 11 SP2)
SUSE Linux Enterprise Server 11 Service Pack 1 (SLES 11 SP1)
SUSE Linux Enterprise Desktop 11

SUSE Linux Enterprise Server 12 Service Pack 1 (SLES 12 SP1)
SUSE Linux Enterprise Server 12 (SLES 12 GA)
SUSE Linux Enterprise Desktop 12

IERS (International Earth Rotation and Reference Systems Service) announced a leap second for 30th June 2015 as per: http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat:

A positive leap second will be introduced at the end of June 2015.
 The sequence of dates of the UTC second markers will be:       
       
                          2015 June 30,     23h 59m 59s
                          2015 June 30,     23h 59m 60s
                          2015 July  1,      0h  0m  0s
             
 The difference between UTC and the International Atomic Time TAI is:

  from 2012 July 1,    0h UTC, to 2015 July 1  0h UTC  : UTC-TAI = - 35s
  from 2015 July 1,    0h UTC, until further notice    : UTC-TAI = - 36s

• Bug #767684 - What SLES and kernel versions are affected by the leap second printk bug
  
• SLES 10 and earlier - not affected
• SLES 11
• SP1 - kernel 2.6.32.59-0.7 and later are safe
• SP2 - kernel 3.0.38-0.5 and later are safe
• SP3 - all are safe
• SP4 - not affected
  
• SLE12 - safe
  

• Bug #768632 (leap second: timer deadlock caused by do_adjtimex)  and Bug #769841 (hang in ktime_get+54)
  
• SLES 10 and earlier - not affected
• SLES 11
• SP1 - kernel 2.6.32.59-0.7 and later are safe
• SP2 - kernel 3.0.38-0.5 and later are safe
• SP3 - all safe
• SP4 - all safe
  
• SLE12 - safe
  

• Bug #771619 (timer expire too early after leap second insertion)
  
• SLES10 and earlier - not affected
• SLES11
• SP1 - kernel 2.6.32.59-0.7 and later are safe
  
• SP2 - kernel 3.0.38-0.5 and later are safe
• SP3 - kernel 3.0.101-0.47.50 and later are safe
• SP4 - not affected
  
• SLE12 - safe
  

• Bug #915335 (Possible deadlock in the leap second fix for Bug #771619)
  
• SLES10 and earlier - not affected
• SLES11
• SP1 - kernel 2.6.32.59-0.19.1 was released mid of April 2015 (LTSS)
  
• SP2 - kernel 3.0.101-0.7.29.1 was released end of March 2015 (LTSS)
  
• SP3 - kernel 3.0.101-0.47.50.1 was released end of March 2015
  
• SP4 - not affected
  
• SLE12 - not affected

• Bug #934601 (Absolute timers that expire at Midnight UTC may fire early when the Leap Second is inserted)
  
• All SLES versions prior to SLES 12 SP2 are potentially affected.
• A fix exists in the kernel 4.4 code base (on which SLES 12 SP2 is based).
• However, the risk of encountering this issue is judged extremely unlikely indeed and it was not encountered during the previous leap second events.
• SUSE development has concluded that the benefits of backporting the fix to earlier service packs are not sufficient to make this worthwhile, given the possible risk of introducing other problems with the backport, and the fact that the code itself has not been tested in a real life leap second situation.
• Any application which could fail in this way would also be vulnerable to an administrative time change.
• Further technical details can be found in the "Additional Information" section below.

• Bug #918342 (slew mode on ntp client does not work properly for Leap Second (SLES 12)
• this bug applies only for SLES 12 systems
• fixed ntp version has been released in May 2015 (ntp-4.2.6p5-44.1)
  
• further technical details can be found in the "Additional Information" section below.
  

SLES 9 is not affected by any know leap second kernel issue, same is valid for SLES 10, reasons are:

• printk is safe to be called unter xtime lock prior to kernel 2.6.22 as per Bug#767684
  
• leap seconds are not handled by hrtimer as in SLES11-SP[12], thus not affected by Bug#769841
• the missing clock_was_set Bug#771619 has been introduced by kernel 2.6.22 by commit 746976a301

Disclaimer: Please note that the above information are based on current known issues and might change in case further issues are being discovered.

This technical document provides additional information to the following TID's from previous Leap Second occurrences:
TID#7010351 - Leap second issues - June 30, 2012
TID#7001865 - Leap second handling in SUSE Linux products

As per TID#7010351: if you can not patch your system before the leap second is triggered, the workaround would be to use "slew" mode:

Switch NTP to "slew" mode 24 hours prior to the leap second and switch back on July 1st.
To achieve this edit /etc/sysconfig/ntp and add option "-x" to the NTPD_OPTIONS, that it looks like
 

NTPD_OPTIONS="-x -g -u ntp:ntp"

afterward restart the ntp service with

rcntp restart

Please make sure to do this prior 23:59:59 UTC 06/29/2015

Technical background:

The workaround changes the NTP service to run in "slew" mode. This will avoid using the adjtime() syscall to inform the kernel of the leap second. While ntp will still use adjtimex() to adjust the clock speed, it will not use it to tell the kernel about the leap second. So the kernel will do nothing special and ntp will correct the 1 second just by slowing the clock down.
When NTP is not in slew mode, the adjtime() syscall can occur anytime within a 24h window prior the leap second.
So it is necessary to switch NTP into slew mode before this 24h window.
When the window is over, the NTP mode can safely be changed back again.

For SLES 12:
Please note that adjtimex package was not part of the initial SLES 12 release but has been added to the SLES12-Updates Channel end of March 2015 and can be installed through that channel (via "zypper in adjtimex").

TID#7016355 was created to provide an overview of test cases for Leap Second.

Bug #934601  (Absolute timers that expire at Midnight UTC may fire early when the Leap Second is inserted):
When the leap second is inserted by the kernel the time is set back by one second from 00:00:00 (UTC) to 23:59:59.
A high resolution timer (using the CLOCK_REALTIME clock and the TIMER_ABSTIME flag) that is scheduled to 00:00:00 may be triggered by the kernel before or in parallel to the leap second handling code. As a result the application that set the timer may be woken with the system clock showing 23:59:59 (i.e. technically "too early").
Such timers may be created by various syscalls, such as:

timer_create/ timer_settime
clock_nanosleep
futex

A list of such timers currently scheduled can be seen in /proc/timer_list. Under clocks that have "-get_time: ktime_get_real". The following command lists all of them:

sed -n '/^  .get_time: *ktime_get_real/,/^ clock/ {/^ #/ p}' /proc/timer_list

It is of course possible that applications may schedule such timers after this file has been checked. That being said, the file does not provide an exhaustive list of potentially affected applications.
The effect of this bug is similar to the scenario of an administrator setting the time back manually by one second, e.g. by using the date command.
The ntpd slew mode workaround will work around this issue, unless the system is  still running an un-patched version of ntpd on SLES 12 that is affected by bsc#918342. In that case ntpd itself will set the time back potentially leading to the same problems.

Bug #918342 (slew mode on ntp client does not work properly for Leap Second)
A generic workaround for most of the Leap Second bugs is to run ntpd in "slew mode". It has been found to not work as expected with some versions of ntpd.

ntpd running in slew mode does not use the adjtimex syscall to inform the kernel of the Leap Second, so all the known and also all potential unknown kernel bugs related to it are avoided.

In previous versions, ntpd running in slew mode also never "stepped" the time, avoiding time going backwards during the Leap Second insertion. Some intermediate versions of ntpd, such as the one originally shipped with SLES 12, set the time back by one second to insert the Leap Second. This was an intentional change by the upstream ntpd developers, but they have recently reconsidered this and agreed it was a bug. For SLES 12 GA and SLES 11 SP4, the current maintenance update version, for SLES 11 SP1 to SP3 the current or final LTSS maintenance update version, of ntpd  does not show this behavior.