Leap Seconds: Problemas en los ajustes horarios (2 de 2)

Tras explicar en la primera de este artículo el porqué de la existencia de los Leap Second, llega el momento de analizar su impacto cuando hay que introducirlos. Cualquier cambio en las condiciones de funcionamiento de un sistema, más cuando se trata de algo tan importante como el tiempo - orquestador de todos los procesos de un sistema -, puede generar situaciones excepcionales que generen excepciones no controladas. Es por eso que, históricamente, los Leap Second han provocado problemas en los sistemas GNU/Linux, ya que utilizan el protocolo NTP para sincronizar el reloj interno del sistema.

Figura 9: ¿Qué pasará cuando tu sistema operativo mienta a las aplicaciones con la hora?
¿Estás listo para el Leap Second del 30 de Junio?

En palabras de Linus Torvalds, creador de Linux, en unas declaraciones, a colación de la próxima inserción el próximo 30 de Junio de un nuevo Leap Second, para la publicación Wired:

“Prácticamente siempre que introducimos un Leap Second encontramos algo nuevo.” “Es muy molesto, porque se trata del claro ejemplo de un código que básicamente nunca se ejecuta, y que no es posible comprobar en condiciones normales”. 

Así que, como se puede ver,  resulta que el mismísimo creador del kernel de Linux - con muy buen criterio, por cierto - afirma que no se sabe a ciencia cierta qué es lo que puede pasar al introducir el Leap Second. Tranquilizador, ¿verdad? Cuando esto suceda, no obstante, se podrá ver en los mensajes de log del kernel de Linux, tal y como se puede ver a continuación.

Figura 10: Mensaje que se verá en los logs del kernel cuando se introduzca el Leap Second

Problemas en el pasado en Linux con la introducción de Leap Seconds

Algunas de las posibles consecuencias de las que habla Linus, se materializaron tanto en el año 2009, como en el año 2012 en forma de “Kernel Dumps” y “Live Locks” producidos en el kernel de Linux.

Figura 11: Problemas reportados tras la introducción de un Leap Second

Figura 12: Bug de condición de carrera en NTP debido al Leap Second

Figura 13: El Kernel de Linux crasheando por culpa del Leap Second de 2009

Figura 14: El Kernel de Linux crasheando por culpa del Leap Second introducido en 2012

Problemas con Leap Seconds en aplicaciones

Lo cierto es que independientemente de los fallos a nivel de kernel, cualquier aplicación que dependa de la serialización de eventos, puede sufrir de la inserción de Leap Seconds si ve, por ejemplo, instantes de tiempo repetidos. El problema se acentúa en sistemas multi-nodo distribuidos, en los que es vital que los relojes se encuentren alineados. Sólo hay que imaginar por ejemplo el caso de dos eventos que van a la misma base de datos con la misma marca temporal. O peor aún, eventos posteriores a otros, que sin embargo quedan con el mismo Timestamp. Está claro que la mayoría del software no está preparado para lidiar con estos Leap Seconds.

Debido al Leap Second introducido en 2012, Gawker, entre otros, sufrió problemas, y se atrevió además a reconocerlo (cosa que otros no hicieron):

“Our web servers running tomcat came close to zero response (we were able to handle some requests),” [...] “We were able to connect to servers in order to reset them. Only rebooting the servers cleared up the issue.”

Software como Java, se vio también afectado por aquel Leap Second, y esto afectó a servicios que corren sobre él, tales como Cassandra y Hadoop. Otras empresas con problemas fueron Foursquare, Yelp, LinkedIn, Mozilla Foundation y StumbleUpon. También se dijo que The Pirate Bay había sido afectada por este bug, pero lo cierto es que no fue así, sino que se trató de una migración de un servidor que salió mal, todo ello en la misma noche en la que se materializó el Leap Second. MySQL sufrió también este bug:

Figura 15: MySQL afectada por el Leap Second

Incluso los servidores de Minecraft fallaron, lo que podía haber sido el fin del mundo si todos los usuarios de este mundo virtual no pudieran entrar a la plataforma ;).

Figura 16: Servidores de MineCraft afectados

Uno de los casos más sonados fue el de Amadeus, la multinacional española de desarrollo de soluciones. El sistema de reservas de Qantas y de Virgin Australia, basado en el software de Amadeus, se vino abajo debido al Leap Second de 2012, imposibilitando a los viajeros facturar, teniendo por tanto que formar largas colas, y provocando retrasos de varias horas, obligando a los trabajadores a realizar la facturación manualmente, como hace décadas.

Figura 17: Consumos superiores a 1 Megavatio en Hetzner

Otro caso interesante, fue el del aumento en el consumo de CPU (debido a un Live Lock) en dos proveedores de hosting, que sufrieron el bug del Leap Second de Linux en 2012 donde Hetzner sufrió una subida en el consumo eléctrico de 1 Megavatio y OVH reportó picos de consumo eléctrico debido a bugs al lidiar con el Leap Second.

Figura 18: Picos de consumo reportados por OVH

Posibles soluciones para evitar problemas con Leap Seconds

El problema que tenemos con los Leap Second, es un problema de base. Tal y como comenta Steve Allen, un programador del Observatorio Lick de California:

“Cuando ocurre un Leap Second, el sistema operativo tiene que ingeniárselas para que el resto de las aplicaciones no se den cuenta”.

Se trata por tanto de “mentiras piadosas” que nos pueden pasar factura. Una comparativa interesante que realiza el propio Steve Allen, es que nos enfrentamos a la misma paradoja que se produce en la película 2001 Una odisea en el espacio, en la que HAL 9000, el ordenador de a bordo, empieza a funcionar mal y a tener comportamientos psicópatas, a partir de ser programada para mentir:

“Le dices al ordenador que mienta, y a partir de ahí ya no se puede tener certeza de lo que pasará a continuación.”

La solución que se ha buscado Google consiste en mentirse a sí mismos, pero muy poco a poco y de manera apenas imperceptible, durante un periodo de 20 horas. Durante ese tiempo previo a la introducción en UTC del Leap Second, Google irá ralentizado gradualmente la hora de los sistemas, de forma que para cuando llegue el momento del Leap Second, los sistemas de Google ya estén en línea con la nueva hora UTC.

Amazon hará algo similar: ralentizará durante un periodo de 24 horas sus relojes, desde las 12 horas previas a la introducción del Leap Second, hasta las 12 horas posteriores. Por tanto, 12 horas después del Leap Second, los relojes estarán en línea con la nueva hora UTC.

Para aquellos que no tengan los recursos de Google o Amazon, y que no se puedan permitir implementar su propia versión de NTP, existe una alternativa. Dicho sea de paso, esta alternativa se podrá utilizar en sistemas que requieran precisión, que no exactitud, en lo que a la sincronización horaria se refiere.

El workaround consiste en ejecutar NTP en modo slew. En dicho modo, NTP no utilizará la llamada adjtime() de cara a informar al kernel de que se ha introducido un Leap Second. Por el contrario, NTP utilizará la llamada adjtimex() para simplemente, ajustar el reloj del sistema, pero ignorando por completo el Leap Second introducido.

Figura 19: Modo slew del daemon de NTP

De esa forma, el kernel no ejecutará ninguna rutina excepcional de cara a tratar el Leap Second, sino que ajustará eventualmente el reloj cuando se percate de que no se encuentra en línea con la hora UTC. Este ajuste lo realizará durante bastante horas, que podrían en algunos casos llegar a ser días. Lo cierto es que en el peor de los casos, durante todo este periodo, el reloj se encontrará desajustado en 1s. Para activar el modo slew, no hay más que reiniciar el demonio NTP, pasándole el flag ‘-x’. Se recomienda realizar este cambio al menos 24 horas antes de que se introduzca el Leap Second, y desactivarlo 24 horas después.

Por último hay que decir que dada la complejidad del problema y las dificultades que se han experimentado en el pasado, existen voces dentro de ITU (International Telecommunication Union) para abandonar por completo la idea de los Leap Second, precisamente por el riesgo que el uso de los mismos entraña. Pero no será hasta noviembre de este año, que es cuando se celebra la WRC-15, que se vuelva a hablar de este tema. Por tanto, tendremos Leap Second el 30 de junio de este año 2015, sí o sí. Veremos cuales son esta vez las consecuencias, si es que las hay…

Figura 20: ¿Habrá situaciones anómalas en la introducción de este Leap Second?

Por otro lado, desde aquí me gustaría lanzar una cuestión, ya que cuando se miente con la hora pasan cosas raras en los sistemas operativos:

¿Creéis que sería posible explotar determinadas vulnerabilidades, o bordear ciertos controles (reglas de firewall, IDS/IPS, iptables, etc…) durante la introducción del Leap Second ¿Cómo pensáis que se comportan determinadas aplicaciones o hardware durante ese preciso instante?

Autor: Ángel Blázquez