Logo
Depuis 1998

Administrateurs, au passage à l’heure d’été : avez-vous pensé à vos tâches planifiées cron ?

Dimanche 31 mars 2013 à 2h, en France ainsi que dans de nombreux autres pays de l’hémisphère nord, il sera immédiatement 3h. Tout comme certains d’entre vous, certains ordinateurs de production seront actifs à cette heure. Si vous êtes administrateur d’un serveur de production, avez-vous pensé à vérifier que vos crontabs et autres schedulers n’ont pas de tâches planifiées entre 2h00 et 2h59 ?

La bonne nouvelle c’est que si vous ne savez pas ce qu’est une crontab ou un cron job, vous n’êtes pas concerné(e), vous pouvez donc vaquer à vos occupations. Les autres, lisez la suite, vous serez peut-être concerné(e)s.

A chaque passage heure d’hiver -> heure d’été, ou l’inverse, il y a matière à réflexion quant aux cron jobs de vos serveurs Unix et Linux, et aux tâches planifiées des serveurs Windows. Il y a plusieurs cas de figures possibles, et une action de précaution à prévoir : écartez vos tâches planifiées du créneau sensible [2h - 2h59].

Les machines pour lesquelles le passage est implémenté

Il s’agit évidemment de l’immense majorité des serveurs de production des zones du monde où le wiki://Paramètres_régionaux/ dicte un tel passage, c’est à dire principalement les pays et territoires situés du delà des tropiques, quel que soit l’hémisphère ; attention, il y a des exceptions.

Pour la suite de cet article, je fais l’hypothèse que l’on parle d’un serveur qui est soumis à un changement d’heure. Pour les autres il n’y a rien à prévoir.

Passage à l’heure d’été

En France, c’est à 2h du matin le dernier dimanche de mars que l’on avance immédiatement d’une heure, donc le créneau [2h00-2h59] n’est jamais vécu ce jour-là, ni par les humains ni par les machines qui sont programmées avec ce passage. Ce qui signifie que tout job programmé dans ce créneau ne sera pas joué à moins que votre version de système d’exploitation implémente la translation de tâche planifiée automatique (ex. OpenServer).
Si, après vérification sur la documentation officielle, il s’avère que l’OS n’implémente pas la reprogrammation automatique des jobs, alors si des jobs planifiées s’agencent dans une séquence où les jobs suivants sont subordonnés par une relation quelconque, comme par exemple la présence de certaines données, ou de certains fichiers créés par les jobs d’avant, il vous faudra translater vers le futur ou le passé, d’une valeur fixe, de façon à ce qu’aucun job ne démarre dans ce créneau inexistant au sens date machine. Si vous n’êtes pas sûr(e) de comment se comporte l’OS, ou n’êtes pas maître de leur durée d’exécution, je vous conseille de les translater vers le futur, donc à partir de 3h00.

Le cas limite de 2h00

Par défaut l’hypothèse est que 2h00 ne donnera lieu à aucune exécution de job, car l’horloge sera modifiée avant que les événements qui lui sont asservis ne se produisent. Dans le doute, appliquez cette hypothèse par principe de précaution.

Passage à l’heure d’hiver

Sans surprise c’est l’effet inverse qui vous guette. A 3h l’horloge système sera repassée à 2h. Ainsi d’éventuelles programmées dans ce créneau serait jouées deux fois, ou tout du moins sera démarrées deux fois, et, selon leur implémentation, pourraient dérouler leur scénario deux fois, avec tous les fois, prévisibles ou pas, qui en découleraient.

Le cas limite de 3h00

Tout comme pour le passage réciproque, celui à l’heure d’été, par défaut l’hypothèse est que 3h00 ne donnera lieu à aucune exécution de job la première fois, car l’horloge sera modifiée avant que les événements qui lui sont asservis ne se produisent, mais la deuxième fois, celui qui se passera donc une heure plus tard, suite au retardement d’une heure, 3h00 sera effectivement joué. Donc au final il ne devrait être joué qu’une seule fois.

Les machines pour lesquelles le passage n’est pas implémenté

De nos jours il est rare que le passage ne soit pas implémenté sur des ordinateurs de production, toutefois, si le cas se présente, il n’y a rien de spécial à prévoir puisqu’au petit matin du dimanche en question, le créneau sensible a été vécu, et les éventuelles tâches exécutées. C’est à vous, en général le dimanche matin ou dans la journée, de mettre à jour l’horloge système dans un sens ou dans l’autre. Si vous êtes debout et devant un ordinateur à l’heure du passage, j’en suis vraiment navré, mais ça arrive, alors surtout ne modifiez pas l’heure système à 2h00 ou à 3h00 avant de vous être assuré(e) qu’il n’y ait pas de jobs qui va être joué deux fois, ou au contraire ignoré.

Conclusion

Si vous êtes administrateur d’une machine de production, ou d’une machine sur laquelle l’exécution des tâches planifiées est importante, alors, quelle que soit la nature du système d’exploitation et de son système de scheduling, vous devriez contrôler la planification des tâches et détecter celles qui sont programmées pour être exécutées le dimanche d’un changement d’heure, dans le créneau [2h00-2h59]. Une fois identifiées, vous devez vous demander quel serait l’effet sur votre système si elles n’étaient pas jouées ce jour-là, ou jouées deux fois ce jour-là. En particulier, font-elles partie d’une séquence de tâches où la suivante est asservie à la précédente ? Si vous n’êtes pas sûr(e), reprogrammez-les en dehors de cette période sensible.

(3786 vues)
créé le 25 mars 2013
révisé le 10 février 2017 par
Accepteriez-vous notre politique de confidentialité ? Elle parle de cookies et de données personnelles...