Discussion :

[petburn]

Bonjour,

je ne sais pas trop ou poser ma question.

on m'a demandé de faire une analyse d'impact du changement d'heure (heure d'été en mars, et heure d'hiver en octobre) sur des traitements qui sont "automatisés" par cron.

Je sais que le changement d'heure a lieu à 2h du matin.

passage heure d'été : à 2h, il sera 3h
les traitements programmés à 2h30 ne seront pas lancé ?

passage heure d'hiver : à 3h, il sera 2h.
les traitements programmés à 2h30 seront lancé 2 fois ?

que faire pour éviter les problèmes à part ne rien programmer entre 2h et 3h

[gangsoleil]

Bonjour,

Changer l'heure sur une machine est toujours problématique.

En effet, outre les problèmes de crontab que tu précises, il peut également survenir d'autres problèmes, notamment sur des dates de production de fichiers dont le nom contient un timestamp : si tu changes l'heure, rien ne t'assure de l'unicité du nom des fichiers, ce qui peut être problématique.

Solution : gérer les machines en temps universel (GMT).

[petburn]

Bonjour,

et merci de ta réponse.

malheuresuement, les machines ne sont pas gérées en temps universel.
(c'est le première question que j'ai posé à l'exploit)

il ne me reste plus grand chose comme solution à part modifier la crontab pour éviter des départs entre 2 et 3h du matin (heure française)

[jlliagre]

passage heure d'été : à 2h, il sera 3h
les traitements programmés à 2h30 ne seront pas lancé ?

non (Solaris)

passage heure d'hiver : à 3h, il sera 2h.
les traitements programmés à 2h30 seront lancé 2 fois ?

oui

que faire pour éviter les problèmes à part ne rien programmer entre 2h et 3h

Mettre le serveur en UTC par défaut.

[petburn]

Le problème, c'est que je doute que "mettre les serveurs en UTC par défaut" soit une solution acceptable (ou du moins qui sera acceptée)

[jlliagre]

Je ne vois pas pourquoi. Le fuseau horaire par défaut d'un serveur n'empêche pas les processus utilisateurs d'utiliser un autre fuseau.

Tu peux aussi mettre uniquement cron en UTC si tu le souhaite.

[jlliagre]

malheuresuement, les machines ne sont pas gérées en temps universel.
(c'est le première question que j'ai posé à l'exploit)

Bien sûr que si. Toutes les machines Unix gèrent leur horloge interne en temps universel. Unix n'est pas Windows. Seule l'heure affichée dépend du fuseau souhaité par l'utilisateur.

[petburn]

OK, merci beaucoup pour les réponses.

comment mettre la cron (uniquement) en UTC ?

[jlliagre]

Ca dépend de ton O/S que tu n'a pas indiqué.

[petburn]

Les OS sont Red hat et SUN O/S

[jlliagre]

As-tu les numéros de version de Red-Hat et Solaris ?

[petburn]

Non, je n'ai pas les version de Red Hat et Solaris.

par contre, on vient de me dire que le solution "mettre la cron en temps TU" n'était pas possible.
Raison : temps trop court avant le passage à l'heure d'été, tous les tests ne pourrons pas être réaliser. donc niet.

[jlliagre]

Tu n'a pas d'autre solution que de lancer tes batches avant 2h00 ou après 3h00 et le problème est réglé.

[frp31]

Bonjour,

je ne sais pas trop ou poser ma question.

on m'a demandé de faire une analyse d'impact du changement d'heure (heure d'été en mars, et heure d'hiver en octobre) sur des traitements qui sont "automatisés" par cron.

Je sais que le changement d'heure a lieu à 2h du matin.

passage heure d'été : à 2h, il sera 3h
les traitements programmés à 2h30 ne seront pas lancé ?

passage heure d'hiver : à 3h, il sera 2h.
les traitements programmés à 2h30 seront lancé 2 fois ?

que faire pour éviter les problèmes à part ne rien programmer entre 2h et 3h

en effet il est tjrs dangereux de placer des taches cron entre 2h et 3h (pour la france) dans certaines boites c'est même purement et simplement interdit sur les machines de prod et à peine toléré pour les machines de dev....

deplus pour les taches de production/exploitation il est recommandé d'utiliser un ordonanceur et non pas le crontab.

=====================================

quoi qu'il en soit l'astuce consiste pour les taches déjà programmés
à écrire un marquer dans /tmp par exemple et interdire donc la double exécution (avec un if en début de tache)

pour le cas de Mars il vaut mieux tricher et programmer un décalage "exceptionnel" de l'exécution. ou encore mieux annuler la mise à jour de lùheure systeme et la réactiver plus tard, et bien sur resyncroniser avec un serveur NTP.