- Un artículo que advierte sobre errores en tareas de cron durante los cambios de horario de verano (DST) en servidores Linux
- Dos veces al año, cuando cambia la zona horaria a las 2:00 o 3:00 a. m. del domingo, pueden ocurrir ejecuciones duplicadas o tareas omitidas
- Como caso real, en un entorno con vixie-cron, una tarea entre las 3:00 y las 3:01 se ejecutó 60 veces a intervalos de 1 segundo, causando congestión de correos electrónicos
- Como solución, se propone configurar la zona horaria en UTC o evitar programar tareas en ese horario, además de desarrollar un mejor scheduler de código abierto
- Un caso que recuerda a administradores de servidores e ingenieros DevOps la importancia de gestionar los riesgos de los cambios de zona horaria
El choque entre el horario de verano y las tareas cron
- Si se programa una tarea cron a las 2:00 o 3:00 a. m. del domingo, puede coincidir con el cambio de horario de verano (DST) y provocar errores de ejecución inesperados
- Cuando empieza el DST, el reloj se adelanta una hora; cuando termina, se atrasa una hora, lo que genera horas duplicadas o ausentes
- Como resultado, las tareas en ese rango pueden ejecutarse dos veces o no ejecutarse en absoluto
- En particular, las tareas que se ejecutan cada domingo de madrugada se ven afectadas en los dos cambios de DST de cada año
- Normalmente funcionan sin problemas, pero en los días de cambio puede haber repeticiones anómalas de ejecución
Caso real: el problema de ejecuciones repetidas en vixie-cron
- Se reportó un caso en vixie-cron sobre Linux donde, al comenzar el DST, una tarea entre las 3:00 y las 3:01 se ejecutó unas 60 veces a intervalos de 1 segundo
- Las tareas entraron en conflicto entre sí y generaron caos, como una avalancha de notificaciones por correo electrónico
- Por suerte, la tarea no era crítica y no hubo daños en el sistema
- Este problema proviene de la estructura simple de scheduling basada en tiempo de cron
- Cron no reconoce cambios de zona horaria ni transiciones de DST, y simplemente ejecuta según la hora configurada
Posibles soluciones y alternativas
- El método más simple es no programar tareas en la franja de las 2:00 y 3:00 a. m. del domingo
- Evitar ese horario permite esquivar por completo los problemas de ejecución duplicada causados por el cambio de DST
- Configurar la zona horaria del servidor en UTC también es una alternativa efectiva
- UTC no aplica horario de verano, por lo que no hay cambios de hora
- Como solución más de fondo, se propone desarrollar un scheduler de tareas más inteligente
- Hace falta una herramienta alternativa de código abierto con funciones como prevención de ejecuciones duplicadas, límites de tiempo de ejecución y reconocimiento de zonas horarias
Propuesta a largo plazo: abolir el horario de verano
- El autor del artículo plantea como solución más deseable la eliminación del DST a nivel gubernamental
- Los dos cambios de hora anuales introducen complejidad innecesaria tanto en la operación de sistemas como en la vida cotidiana
- Pero mientras el DST siga existiendo, los administradores de sistemas y los ingenieros DevOps deben tomar medidas preventivas
- Hay que prestar especial atención a tareas dependientes del tiempo como procesos por lotes automatizados, respaldos y rotación de logs
Conclusión: principios para programar cron de forma segura
- Hay que evitar las tareas entre las 2:00 y las 3:00 a. m. en los cambios de DST
- Siempre que sea posible, usar servidores basados en UTC para eliminar problemas de zona horaria
- Conviene reconocer las limitaciones de cron y evaluar la adopción de herramientas de scheduling más robustas
- En entornos DevOps, gestionar correctamente las zonas horarias y asegurar la confiabilidad de la automatización es una tarea esencial
2 comentarios
Yo también, después de tener problemas con una tarea programada para las 2 a. m. (a veces se ejecutaba dos veces y otras no se ejecutaba), me aseguro de evitarlo siempre.
Comentarios de Hacker News
Creo que el DST (horario de verano) es un sistema completamente equivocado
No resuelve ningún problema y solo genera inconvenientes
Simplemente habría que quedarse con la hora estándar de forma fija y, en cambio, adelantar el horario laboral una hora como en verano
Por ejemplo, abrir las tiendas a las 6 en vez de a las 7 y cerrar a las 9 en vez de a las 10
De todos modos ya hay un periodo de adaptación dos veces al año, así que bastaría con cambiarlo una sola vez
Quiero ver más luz solar después del trabajo. En invierno todavía más, y no me importa si el sol ya salió cuando voy al trabajo
Como voy a estar encerrado 9 horas en interiores, prefiero ver el sol cuando tengo tiempo libre
Por ejemplo, estuvo el experimento de DST durante todo el año en EE. UU. entre 1973 y 1975
Al principio tenía mucho apoyo por motivos como el ahorro de energía y la reducción del crimen, pero
la opinión pública cambió bruscamente por los accidentes de camino a la escuela en mañanas oscuras, y al final se abandonó
(cita de Wikipedia)
Al final suena como si lo que se quisiera fuera un desplazamiento horario todavía mayor
Solo existen la hora estándar y el horario de verano
Decir que se quiere mantener siempre la “hora de invierno” no resulta psicológicamente atractivo
La gente quiere empezar el día cuando ya hay luz
Los programadores sufren por el DST, pero creo que eso es un problema de manejar bien los casos límite
Como cada persona tiene patrones de sueño distintos, si todos pudieran elegir el horario que mejor les queda, habría menos conflicto
Cuando hace tiempo configuré los servidores de reddit, los puse todos en la zona horaria de Arizona
Arizona no usa DST, así que solo hay una diferencia de 1 hora con California
La razón para no usar UTC era que, al leer logs, “es más fácil restar 1 que restar 8”
Ahora ya tenemos un equipo global, así que se cambió a UTC
Lo mejor es unificar todo en UTC desde el principio
Estos cambios ocurren con frecuencia en todo el mundo, y para quienes desarrollan apps de calendario eso es realmente un dolor de cabeza
Si elegiste UTC, deberían asumir que entiendes el formato YYYY-MM-DD de 24 horas
pero dentro de la organización cada quien la cambiaba a PST y eso generaba confusión porque cada log mostraba horas distintas
Al final el líder intervino y unificó todas las aplicaciones y bases de datos en PST
Aun así, ya terminé interpretando UTC casi por instinto
Antes configuré los servidores de una empresa en BST (British Summer Time) y usábamos mucho cron,
así que el caos se repetía dos veces al año
Al final nunca logramos arreglarlo antes de que la empresa quebrara
La lección es simple: usa UTC, salvo que tengas una razón especial para no hacerlo
Por ejemplo, los reseteos de límites de uso o los procesos batch de facturación corren según la hora regional
Por ejemplo, un reporte de las 8:00 en Reino Unido cambia en UTC dependiendo del DST
Por eso UTC por sí solo no basta, y hay que guardar también la información de zona horaria
En algunos países (Cuba, Egypt, Lebanon), los cambios de DST ocurren a medianoche
(enlace relacionado)
En Brasil era común que cambiara entre 00:00~01:00 o 00:00~23:00
Hay estudios que muestran que en los días de ajuste del DST aumentan bruscamente la mortalidad y las visitas a urgencias
(artículo de ScienceAlert)
Más allá del problema de cron, el DST es también una práctica dañina para la salud
Este problema ya se había resuelto hace mucho tiempo en OpenBSD y Debian
En el manual de cron(8) de Debian se explica la lógica para manejar desplazamientos de tiempo menores a 3 horas durante ajustes de DST
(enlace al parche,
manual,
reporte de bug)
El consejo es no programar tareas a la medianoche (00:00)
Como la fecha puede prestarse a confusión, conviene usar horas raras como 00:01 o 01:45
Así es más fácil rastrear la causa cuando el sistema se comporta raro a ciertas horas
Pero en entornos que usan reloj de 12 horas sí puede haber confusión
Antes de sufrir problemas de zona horaria no lo sabía,
pero en el mundo existen horas inexistentes y horas ambiguas
Por ejemplo, cuando se pasa de las 2 a las 3, las 2:30 no existe,
y cuando el reloj se atrasa, las 2:30 ocurre dos veces
Como la hora del ajuste de DST cambia según el país, en sitios como Chile puede desaparecer la medianoche
(blog relacionado)
Recuerdo que Java y Ruby manejaban esta situación de forma distinta, y al principio de mi tiempo en Stripe eso nos causó tres incidentes seguidos
En las tareas de cron conviene evitar la hora exacta y, si es posible, programarlas después de las 4 a. m. o antes de medianoche
En infraestructura compartida suele haber mucha competencia por recursos justo a la hora en punto
sleep $(( $(od -N1 -tuC -An /dev/urandom) % 60 ))m ;antes del comando de cronpara añadir un retraso aleatorio de 0 a 59 minutos
Las tareas programadas importantes deberían diseñarse, en la medida de lo posible, para ser idempotent (seguras ante ejecuciones duplicadas)
Sobre todo cuando hay sistemas de colas involucrados, este tipo de diseño es clave para prevenir problemas