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:
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
Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
6 comentarios:
Por poder seguro que hay alguna forma imaginativa de explotar de forma maliciosa los leap seconds.
Siempre me había preguntado como se getionan los leap seconds en sistemas operativos. Nunca lo he tenido en cuenta a la hora de desarrollar software, porque siempre he supuesto que el sistema operativo revolverá el asunto y durante el leap second en cada llamada a obtener el instante de tiempo dará distintas lecturas.
Me ha parecido muy interesante el artículo completo, y estaba expectante por leer la pregunta final, pues es la que me había estado haciendo desde que empecé a leerlo: ¿cómo se podrán sacar ventajas, de cualquier tipo y desde cualquier punto de vista, de la implementación de los leap seconds?
Como curiosidad, este fenómeno me recuerda a una anécdota histórica real. Por un problema de causas similares, cuando intentaron corregir los errores de cálculo del calendario juliano allá por 1582, se dieron cuenta de que la duración de los días era distinta a la que hasta entonces se creía (por observaciones y predicciones de eclipses, sobre todo). La solución fue sencilla pero algo radical: del jueves 4 pasaron directamente al viernes 15 de octubre, perdiéndose diez días por el camino. La pobre Santa Teresa de Jesús, fallecida poco antes de la noche del jueves, estuvo de cuerpo presente más de una semana hasta que fue finalmente enterrada el día 15. A partir de ese momento empezaron a tener en cuenta muchas variables que hasta entonces resultaban desapercibidas.
Por último, no me gustaría irme sin plantear una cuestión. ¿Cómo afectan los cambios de horario de verano/invierno, introducidos por Benjamín Franklin, a los sistemas informáticos? Me encantaría conocer la respuesta de un problema que llevo algún tiempo planteándome.
Enhorabuena a Ángel por su artículo y un saludo.
Excelente explicación. Felicitaciones.
Buenas, es primera vez que leo al respecto de esto. Tengo una pregunta, ¿sólo sufren los sistemas GNU/Linux? ¿o también toda la familia de Unix? ¿Podría un Solaris, HP-UX, o AIX verse afectado por este problema?
Gracias.
A mi, lo de engañar al reloj dándole la hora falsa me ha recordado la película "La Trampa" de Sean Conery y Catherine Zeta-Jones. Creo que ahí se engañaba al reloj para poder robar dinero.
Sobre el cambio de calendario juliano a gregoriano: El cambio se hizo en diferentes años dependiendo de cada país. Puedes buscar cuando se hizo el cambio en los diferentes paises. Entre las anécdotas está la de la revolución soviética de octubre. En los paises con el calendario gregoriano fue en noviembre.
Publicar un comentario