Dimanche machinalement, je regarde l'état de ma sauvegarde… Pas de mail !
Cela m’a tracassé toute la nuit.
Inquiet ce matin, j'arrive et essaie de comprendre pourquoi. Elle était bien programmé à 3 heures… Le décalage horaire.
C’était une tâche planifiée sous Windows. Je n’ai que ce que je mérite :).
Après réflexions, d’avoir un potentiel bug qui n’arrive que deux fois par an, c'est à dire une omission d’exécution ou une double exécution.
Je me suis renseigné un peu.
Si j'avais utilisé Crontab sous Linux(et peut être les autres Unix). Le décalage horaire aurait été pris en compte http://fr.wikipedia.org/wiki/Crontab et cette omission n’aurait pas eu lieu ainsi que la potentielle double exécution au mois d’octobre.
Toutefois, on peut se retrouver avec un comportement non prévu si nous avions deux scripts qui s’exécutent avec une heure intervalle. Il risquerait alors de s’exécuter en même temps au passage à l'heure d'hiver.
# Pas compris...
Posté par windu.2b . Évalué à 4.
Pourquoi la tâche planifiée ne s'est-elle pas exécutée ? L'heure étant passée de 2h à 3h, elle aurait dû se faire quand même (mais 1h plus tôt que prévu), non ?
[^] # Re: Pas compris...
Posté par syj . Évalué à 3.
Je me suis aussi posé la question. Elle était configuré à 3h00. Peut être que le changement d'heures. C'est appliqué à 2h00 et 59s.
Si le gestionnaire de tâches scanne toutes les minutes: 2h00 rien à faire , 3h01 rien à faire…
# UTC Rulez
Posté par fearan . Évalué à 8.
Oui enfin pour un serveur, j'aurais tendance à le laisser en UTC, ce qui n’affecterai pas le Cron.
C'est quoi cette manie de changer l'horloge interne de son PC, alors qu'il peut prendre en compte l'affichage de l'heure locale.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: UTC Rulez
Posté par Strash . Évalué à 4.
C'est pas très pratique d'avoir a faire une gymnastique pour calculer l'heure à entrer dans cron lorsqu'on veut mettre une tache à une certaine heure locale…
[^] # Re: UTC Rulez
Posté par fearan . Évalué à 2.
Bah regarde du coté de fcron ou anacron si tu estimes que c'est vital.
mais pour un serveur, j'aime bien avoirs des logs cohérents par exemple.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: UTC Rulez
Posté par steph1978 . Évalué à 3.
Si le travail doit effectivement se dérouler à l'heure locale, ça ne change pas le problème. Enfin si, ça le déplace du service cron vers le programme applicatif.
Si le travail peut s'effectuer à une heure pas trop important, genre "dans la nuit", ne pas choisir une heure entre 2h00 et 3h30 éviterai ces problème.
Il fait quoi cron pour un job planifié à 2h30, heure qui n'existe pas le 24 mars ?
[^] # Re: UTC Rulez
Posté par syj . Évalué à 2.
D'après le man, il l'exécutera tout job de 2h01 à 3h00 à 3h00 (nouvelle heure). En fait , tout changement d'heures de moins de 3 heures pour une heure fixe (sans *) sera pris en compte.
[^] # Re: UTC Rulez
Posté par syj . Évalué à 1.
Je ne crois pas que cela soit si évident que ça. Il faut aussi que tes applications prennent en compte l'affichage de l'heure locale.
Il faut donc que les devs des applis le prenne en compte. Et typiquement , dans mon cas, je n'y avais jamais pensé.
Il y a peu, j'ai développé un planning de garde. Le serveur était en UTC. J'ai été au plus simple , j'ai changé le timezone :).
Je pense que maintenant je le prendrais en compte pour mes prochains dev.
[^] # Re: UTC Rulez
Posté par fearan . Évalué à 3.
en même temps pour une appli isolé sur un poste bureautique, la question peut se poser, c'est plus simple.
Mais dès que l'appli doit jouer avec une BDD, ou que les machines peuvent êtres sur plusieurs sites, il est beaucoup plus simple de mettre toutes les machine en UTC, sinon au moindre soucis, c'est la galère avec les logs, les dates enregistrés et tout le toutim.
depuis le C89 (et SVr4 ) on a localtime et gmtime (au niveau de la norme je parle), c'est pas comme si les outils n'étaient pas déjà là.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: UTC Rulez
Posté par kabhal . Évalué à 5.
J'ai également pris l'habitude de passer tous les serveurs en UTC.
D'expérience, il y a des bugs avec les changements d'heure a peu près à tous les niveaux, chaque couche rajoutant des bugs pour corriger les bugs de la couche du dessous (quand c'est volontaire ! pour les BDD notamment), c'est même pas la peine d'espérer lutter.
Donc règle simple : dès qu'il y a un calcul sur une date à faire, tout doit être stocké/manipulé en UTC.
L'affichage en heure locale est à faire au dernier moment au niveau de l'interface finale avec l'utilisateur.
Je pense surtout au développement mais çà vaut aussi pour l'administration.
# Quand Windows change d'heure, les fichiers aussi
Posté par Nonolapéro . Évalué à 7.
Pour je ne sais quelle raison, lors du passage à l'heure d'été ou d'hiver, Windows change également l'heure de dernière modification des fichiers. Du coup si tu synchronises tes fichiers via la dernière modification tu dois tout recopier.
[^] # Re: Quand Windows change d'heure, les fichiers aussi
Posté par Zenitram (site web personnel) . Évalué à 6.
Je ne voulais pas te croire tellement c'est énorme comme truc, pas possible que la date de modification (affichée du moins) change suivant l'heure d'été/d'hiver, ça doit quand même être bien géré et affiché l'heure du moment de la modif… Mais non. Gloups. Vraiment bien pourri, on ne sait pas vraiment à quelle heure ça a été modifié finalement.
Vive rsync :) (à priori, il doit se baser sur l'heure UTC, je n'ai pas de checksum fait sur les fichiers entre machines Windows et Linux)
[^] # Re: Quand Windows change d'heure, les fichiers aussi
Posté par Claude SIMON (site web personnel) . Évalué à 1.
Petit réserve concernant 'rsync'.
Il m'arrive de faire une sauvegarde complète de fichiers sous 'Windows', en utilisant 'rsync' sous 'Cygwin', à destination de la carte mémoire de mon smartphone branché via USB, en mode UMS donc. Je réalise ensuite régulièrement des sauvegardes incrémentales, toujours en utilisant 'rsync' sous 'Cygwin', mais en me connectant au smartphone (qui est sous 'GNU/Linux') par Wi-Fi.
J'ai dû écrire un script qui recule l'horodatage de modification des fichiers de 1 ou 2 heures, selon que l'on soit en heure d'hiver ou d'été, que je dois lancer immédiatement après la sauvegarde complète, sinon la première sauvegarde incrémentale transfère l’ensemble des fichiers, et non pas seulement ceux qui ont été modifiés depuis la sauvegarde complète.
J'ai cherché dans les options de 'rsync', mais je n’ai rien trouvé qui permette de me passer de mon script. Si quelqu'un à une idée…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Quand Windows change d'heure, les fichiers aussi
Posté par Kerro . Évalué à 2.
C'est un bug que je connais depuis Windows NT. Donc trèèès ancien. Vive la réactivité.
Je n'ai jamais tenté de trouver la raison de la chose, mais c'est tellement connu que pas mal de logiciels contournent ça dans leur code. En particulier les logiciels de sauvegarde.
# Toi aussi, décale ton heure !
Posté par Zarmakuizz (site web personnel) . Évalué à 10.
Tout simplement, mets ton script à 4 ou 5h du matin.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.