impacts programmes crontab et changement d'heure

petburn · 10/03/2008, 15h15

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 · 11/03/2008, 09h12

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 · 11/03/2008, 09h28

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 · 11/03/2008, 09h38

Citation:

Envoyé par petburn

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

non (Solaris)

Citation:

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

oui

Citation:

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

Mettre le serveur en UTC par défaut.

petburn · 11/03/2008, 10h45

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 · 11/03/2008, 11h04

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 · 11/03/2008, 11h06

Citation:

Envoyé par petburn

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 · 11/03/2008, 11h15

OK, merci beaucoup pour les réponses.

comment mettre la cron (uniquement) en UTC ?

jlliagre · 11/03/2008, 13h17

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

petburn · 11/03/2008, 17h10

Les OS sont Red hat et SUN O/S

jlliagre · 11/03/2008, 18h41

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

petburn · 12/03/2008, 09h29

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 · 12/03/2008, 15h52

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 · 13/03/2008, 09h17

Citation:

Envoyé par 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

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.

10/03/2008, 15h15	#1
petburn Invité régulier Inscription : mai 2002 Messages : 37 Détails du profil Informations personnelles : Âge : 30 Informations forums : Inscription : mai 2002 Messages : 37 Points : 8 Points : 8	impacts programmes crontab et changement d'heure 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
	00

11/03/2008, 09h12	#2
gangsoleil Modérateur R&D en systemes informatiques bas niveau Unix/Linux Inscription : mai 2004 Messages : 5 499 Détails du profil Informations personnelles : Âge : 31 Localisation : France, Isère (Rhône Alpes) Informations professionnelles : Activité : R&D en systemes informatiques bas niveau Unix/Linux Informations forums : Inscription : mai 2004 Messages : 5 499 Points : 9 682 Points : 9 682	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). __________________ Modérateur "C", "Informatique Générale & Hardware" et "Unix" Les règles du forum
	00

11/03/2008, 09h28	#3
petburn Invité régulier Inscription : mai 2002 Messages : 37 Détails du profil Informations personnelles : Âge : 30 Informations forums : Inscription : mai 2002 Messages : 37 Points : 8 Points : 8	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)
	00

11/03/2008, 10h45	#5
petburn Invité régulier Inscription : mai 2002 Messages : 37 Détails du profil Informations personnelles : Âge : 30 Informations forums : Inscription : mai 2002 Messages : 37 Points : 8 Points : 8	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)
	00

11/03/2008, 11h04	#6
jlliagre Membre Expert Inscription : juin 2007 Messages : 970 Détails du profil Informations personnelles : Localisation : France, Paris (Île de France) Informations forums : Inscription : juin 2007 Messages : 970 Points : 1 377 Points : 1 377	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.
	00

11/03/2008, 11h15	#8
petburn Invité régulier Inscription : mai 2002 Messages : 37 Détails du profil Informations personnelles : Âge : 30 Informations forums : Inscription : mai 2002 Messages : 37 Points : 8 Points : 8	OK, merci beaucoup pour les réponses. comment mettre la cron (uniquement) en UTC ?
	00

11/03/2008, 13h17	#9
jlliagre Membre Expert Inscription : juin 2007 Messages : 970 Détails du profil Informations personnelles : Localisation : France, Paris (Île de France) Informations forums : Inscription : juin 2007 Messages : 970 Points : 1 377 Points : 1 377	Ca dépend de ton O/S que tu n'a pas indiqué.
	00

11/03/2008, 17h10	#10
petburn Invité régulier Inscription : mai 2002 Messages : 37 Détails du profil Informations personnelles : Âge : 30 Informations forums : Inscription : mai 2002 Messages : 37 Points : 8 Points : 8	Les OS sont Red hat et SUN O/S
	00

11/03/2008, 18h41	#11
jlliagre Membre Expert Inscription : juin 2007 Messages : 970 Détails du profil Informations personnelles : Localisation : France, Paris (Île de France) Informations forums : Inscription : juin 2007 Messages : 970 Points : 1 377 Points : 1 377	As-tu les numéros de version de Red-Hat et Solaris ?
	00

12/03/2008, 09h29	#12
petburn Invité régulier Inscription : mai 2002 Messages : 37 Détails du profil Informations personnelles : Âge : 30 Informations forums : Inscription : mai 2002 Messages : 37 Points : 8 Points : 8	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.
	00

12/03/2008, 15h52	#13
jlliagre Membre Expert Inscription : juin 2007 Messages : 970 Détails du profil Informations personnelles : Localisation : France, Paris (Île de France) Informations forums : Inscription : juin 2007 Messages : 970 Points : 1 377 Points : 1 377	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é.
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email