- Un article qui met en garde contre les erreurs de tâches cron sur les serveurs Linux lors des transitions à l’heure d’été (DST)
- Deux fois par an, le dimanche à 2 h ou 3 h du matin, le changement de fuseau horaire peut entraîner l’exécution en double ou l’omission de tâches cron
- Cas réel à l’appui : dans un environnement vixie-cron, une tâche entre 3 h 00 et 3 h 01 a été relancée 60 fois à 1 seconde d’intervalle, provoquant un engorgement des e-mails
- Solutions proposées : configurer le fuseau horaire en UTC ou éviter les tâches à cette heure, voire développer un meilleur ordonnanceur open source
- Un exemple qui rappelle aux administrateurs système et aux ingénieurs DevOps l’importance de gérer les risques liés aux changements de fuseau horaire
Collision entre l’heure d’été et les tâches cron
- Planifier des tâches cron le dimanche à 2 h ou 3 h du matin peut provoquer des erreurs d’exécution imprévues au moment du passage à l’heure d’été (DST)
- Au début du DST, l’horloge avance d’une heure, et à sa fin, elle recule d’une heure, ce qui crée des heures dupliquées ou manquantes
- Cela peut conduire à des tâches exécutées deux fois ou pas du tout selon le créneau concerné
- Les tâches lancées chaque semaine le dimanche à l’aube sont particulièrement exposées lors des deux transitions DST annuelles
- En temps normal, elles fonctionnent sans problème, mais les jours de changement d’heure, des répétitions anormales d’exécution peuvent survenir
Cas réel : problème de répétition dans vixie-cron
- Dans un environnement Linux utilisant vixie-cron, un cas a été signalé où, au début du DST, une tâche entre 3 h 00 et 3 h 01 a été exécutée environ 60 fois à 1 seconde d’intervalle
- Les tâches entraient alors en conflit les unes avec les autres, provoquant notamment une avalanche d’e-mails de notification
- Heureusement, la tâche concernée n’était pas critique, et aucun dommage système n’a été constaté
- Ce type de problème découle de la structure de planification purement horaire et très simple de cron
- Cron ne tient pas compte des changements de fuseau horaire ni des transitions DST et se contente d’exécuter la tâche à l’heure indiquée
Solutions possibles et alternatives
- La méthode la plus simple consiste à ne pas planifier de tâches le dimanche entre 2 h et 3 h du matin
- En évitant ce créneau, on supprime complètement le risque de double exécution lié au changement d’heure
- Configurer le fuseau horaire du serveur en UTC est également une alternative efficace
- L’UTC n’applique pas l’heure d’été, donc aucun changement d’heure ne se produit
- Une solution plus fondamentale serait de développer un ordonnanceur de tâches plus intelligent
- Un outil alternatif open source doté de fonctions comme la prévention des doublons, la limitation du temps d’exécution et la gestion des fuseaux horaires serait nécessaire
Proposition à long terme : supprimer l’heure d’été
- L’auteur présente comme solution la plus souhaitable l’abolition du DST au niveau gouvernemental
- Les deux changements d’heure annuels introduisent une complexité inutile, aussi bien pour l’exploitation des systèmes que pour la vie quotidienne
- Mais tant que le DST demeure en vigueur, les administrateurs système et les ingénieurs DevOps doivent prendre des mesures préventives
- Il faut être particulièrement vigilant avec les tâches dépendantes du temps comme les traitements batch automatisés, les sauvegardes ou la rotation des logs
Conclusion : principes de planification cron sûrs
- Il faut éviter les tâches entre 2 h 00 et 3 h 00 au moment des transitions DST
- Si possible, faire tourner les serveurs en UTC pour éliminer les problèmes de fuseau horaire
- Il faut reconnaître les limites de cron et envisager l’adoption d’outils de planification plus robustes
- Dans un environnement DevOps, la gestion des fuseaux horaires et la fiabilité de l’automatisation sont des enjeux essentiels
2 commentaires
Depuis que j’ai eu des problèmes avec une tâche programmée à 2 heures du matin (une fois elle s’exécutait deux fois, une autre fois pas du tout), j’évite absolument ce créneau moi aussi.
Commentaires Hacker News
Je pense que le DST (heure d’été) est un système complètement absurde
Il ne résout aucun problème et ne fait qu’ajouter des désagréments
Il suffirait de rester en heure standard toute l’année et d’avancer les horaires de travail d’une heure en été
Par exemple, ouvrir les magasins à 6 h au lieu de 7 h, et les fermer à 21 h au lieu de 22 h
Puisqu’il faut déjà s’adapter deux fois par an, autant ne faire le changement qu’une seule fois
J’aimerais surtout avoir plus de lumière après le travail. C’est encore plus vrai en hiver, et peu m’importe qu’il fasse jour pendant le trajet du matin
Si je vais être enfermé 9 heures à l’intérieur, je préfère voir le soleil pendant mon temps libre
Par exemple, les États-Unis ont expérimenté le DST toute l’année entre 1973 et 1975
Au départ, l’opinion y était favorable pour des raisons comme les économies d’énergie et la baisse de la criminalité,
mais les accidents sur le trajet scolaire dans l’obscurité matinale ont rapidement fait basculer l’opinion, et la mesure a finalement été abandonnée
(citation Wikipédia)
On dirait même que cela revient à demander un décalage horaire encore plus important
Il n’y a que l’heure standard et l’heure d’été
Dire qu’il faudrait garder en permanence « l’heure d’hiver » n’est pas psychologiquement très vendeur
Les gens veulent commencer leur journée quand il fait jour
Les programmeurs souffrent à cause du DST, mais à mon avis c’est surtout un problème de bonne gestion des cas limites
Comme les rythmes de sommeil diffèrent d’une personne à l’autre, on aurait moins de conflits si chacun pouvait choisir les horaires qui lui conviennent
Quand j’ai configuré les serveurs de reddit autrefois, je les ai tous mis sur le fuseau horaire de l’Arizona
L’Arizona n’utilise pas le DST, donc il n’y a qu’une heure d’écart avec la Californie
Je n’avais pas choisi UTC parce que, pour lire les logs, « il est plus simple de soustraire 1 que de soustraire 8 »
Aujourd’hui, l’équipe est devenue mondiale, donc tout a été migré vers UTC
Il vaut mieux tout unifier en UTC dès le départ
Ce genre de changement arrive souvent dans le monde entier, et pour les développeurs d’applications de calendrier c’est un vrai casse-tête
Si l’on a choisi UTC, on devrait partir du principe que l’utilisateur comprend le format YYYY-MM-DD sur 24 heures
mais dans une organisation, chacun l’avait changé en PST de son côté, ce qui a créé une grande confusion avec des heures différentes selon les logs
Finalement, un responsable est intervenu pour uniformiser toutes les applications et toutes les bases de données en PST
Mais avec le temps, j’ai fini par interpréter l’UTC instinctivement
Autrefois, j’avais configuré les serveurs de l’entreprise en BST (British Summer Time) et j’utilisais beaucoup cron,
ce qui provoquait la même confusion deux fois par an
Nous n’avons jamais réussi à corriger ça avant la faillite de l’entreprise
La leçon est simple — utilisez UTC, sauf raison particulière
Par exemple, des tâches comme les réinitialisations de quotas d’usage ou les batchs de facturation tournent selon l’heure locale
Par exemple, un rapport de 8 h au Royaume-Uni correspond à une heure UTC différente selon le DST
Donc UTC seul ne suffit pas, et il faut stocker aussi l’information de fuseau horaire
Dans certains pays (Cuba, Égypte, Liban), le changement DST se produit à minuit
(lien connexe)
Au Brésil, il était courant que cela change entre 00:00 et 01:00, ou entre 00:00 et 23:00
Une étude indique que la mortalité et les passages aux urgences augmentent fortement les jours de changement DST
(article de ScienceAlert)
Au-delà des simples problèmes de cron, le DST est aussi un système nocif pour la santé
Ce problème a déjà été résolu il y a longtemps dans OpenBSD et Debian
Le manuel cron(8) de Debian décrit une logique de traitement des sauts de temps de moins de 3 heures lors des changements DST
(lien du patch,
manuel,
rapport de bug)
Le conseil est de ne pas planifier de tâche à minuit (00:00)
Comme la date prête facilement à confusion, mieux vaut choisir une heure un peu atypique comme 00:01 ou 01:45
Cela facilite l’identification de la cause quand le système a un comportement étrange à une heure précise
En revanche, dans les environnements qui utilisent l’horloge sur 12 heures, cela peut créer de la confusion
Avant d’avoir été confronté aux problèmes de fuseaux horaires, je ne savais pas qu’il existait dans le monde des heures inexistantes et des heures ambiguës
Par exemple, quand on passe de 2 h à 3 h, 2 h 30 n’existe pas,
et lorsqu’on recule l’heure, 2 h 30 existe deux fois
Chaque pays change le DST à une heure différente, si bien que dans des cas comme le Chili, minuit peut disparaître
(billet de blog connexe)
Je me souviens qu’au début de mon passage chez Stripe, Java et Ruby géraient cette situation différemment, ce qui a provoqué trois incidents d’affilée
Pour les tâches cron, j’évite les heures piles et, si possible, je les programme après 4 h du matin ou avant minuit
Sur une infrastructure partagée, la contention sur les ressources est forte aux heures piles
sleep $(( $(od -N1 -tuC -An /dev/urandom) % 60 ))m ;pour introduire un retard aléatoire de 0 à 59 minutes est aussi une bonne méthode
Les tâches planifiées importantes devraient autant que possible être idempotentes (sans risque en cas d’exécution en double)
Surtout quand un système de files d’attente est impliqué, ce type de conception est essentiel pour prévenir les problèmes