Como protegerse de los efectos colaterales del Leap Second

Para los que administráis sistemas, seguramente sabréis que este próximo 30 de Junio de 2015 se añadirá 1s al UTC (Tiempo Universal Coordinado) con el fin de sincronizar los relojes atómicos con el tiempo solar medio (tiempo que tarda la tierra en realizar una rotación completa sobre su eje). Es lo que en inglés se llama Leap Second. Desde el uso de relojes atómicos, cuya frecuencia es estable e invariable, hay que añadir 1s cada cierto tiempo para compensar que la rotación de la tierra ha ido reduciendo su velocidad y así sincronizar las 24h del día solar con el reloj atómico. Para más información puede consultarse la wikipedia:Leap Second – Segundo Intercalar.
Pero en este blog nos atañe la tecnología, aunque nos guste la ciencia también, y vamos a ver como pueden verse afectados los sistemas cuando se corrija la hora este 30 de Junio de 2015 y ver como protegerse de los efectos colaterales del Leap Second.

Este 30 de Junio de 2015 a las 23:59:59 se añadirá 1s y la siguiente hora será el 30 de Junio de 2015 23:59:60 y no 1 de Julio de 2015 a las 0:00:00. Este segundo se añade a través del protocolo de sincronización de tiempo NTP, el cual tiene en cuenta la adición del Leap Second y tiene definido un flag para ello. Si tu sistema no está sincronizado por NTP, no va a ver la adicción del segundo, y quedará un segundo retrasado respecto el UTC. Pero si está sincronizado, el sistema tendrá un segundo adicional y esto puede provocar varios problemas en el sistema operativo, como por ejemplo un kernel panic y la parada total del sistema. Así que no es un asunto trivial. Y para ejemplo, basta ver los efectos que hubo la última vez que se añadió un leap second (en 2012), desde el blog “Un informatico en el lado del mal” lo enumeran: Leap Second: Problemas en los ajustes horarios.

Son los sistemas UNIX/LINUX, concretamente el kernel, los que sufren los efectos. Cuando se añade el segundo adicional, se entra en un estado no contemplado por el sistema (23:59:60), en el cual no sabe cómo proceder, por ejemplo no saber a que proceso dar el siguiente ciclo de cpu y puede generarse un “race condition” que provoque el cuelgue del sistema. Desde el 2012, han aprendido los responsables de las distribuciones de Linux y ya hay actualizaciones y parches que preparan el sistema para este segundo adicional, cuando el flag del leap second viene en el paquete NTP.

• RedHat: Resolve Leap Second Issues in Red Hat Enterprise Linux
• Suse: Fixes and workaround to avoid issues caused by Leap Second 2015
• Y así con el resto de distros

Pero no sólo Linux, también los equipos de comunicaciones están afectados (al final están basados en kernel linux/unix):

• CheckPoint: Check Point response to Leap Second introduced in UTC on 30 June 2015
• Cisco: Leap Second
• Igualmente, el resto de fabricantes

Si estas leyendo esto y no sabes si estás preparado, la recomendación es DESHABILITA EL NTP. Pero no es una decisión sencilla, dependerá del la función que haga el sistema, las aplicaciones que corran en él, si se trata de un cluster con más nodos, etc. Pero por lo general, si deshabilitas el NTP 12h antes, cuando pasen las doce de la noche, sólo tendrás 1s de retraso respecto al UTC. Después vuelve a activar el NTP y sincronizarás el tiempo correctamente, sin sufrir ninguna consecuencia. Repito, esto en caso de que tu sistema pueda permitirse estar sin sincronización (lo más crítico son los cluster, donde los nodos que forman el cluster tienen que estar sincronizados en tiempo y también las BBDD).