Vous le savez peut-être mais la rotation de la terre ne fait pas tout à fait 24h. Je vous rassure, ça tombe vraiment pas loin. Mais il arrive de temps en temps qu'il faille corriger cet écart. C'était le cas ce week-end avec l'introduction d'une « leap second » : samedi à minuit, une minute a duré 61 secondes au lieu des 60 secondes habituelles.
Petit changement, mais conséquences non-négligeables : beaucoup de code écrit sur cette planète n'est pas prévu pour ce cas là. Si votre serveur est en vrac ce matin, ne cherchez pas, il y a de bonnes chances pour que le coupable soit cette « leap second ». Dans la liste des processus qui peuvent être impactées, on retrouve Java et MySQL (ils se mettent à consommer plein de CPU), mais aussi le noyau Linux (ouch).
Sur le serveur de LinuxFr.org, nous étions touché : l'Elastic Search (java) utilisé pour le moteur de recherche tournait à fond. On a pu corriger ça simplement grâce à une astuce trouvée sur un blog mozilla :
/etc/init.d/ntpd stop; date -s "`date`"
Voici quelques autres liens sur le sujet :
# Ne pas oublier LC_ALL=C
Posté par Misc (site web personnel) . Évalué à 10.
Perso, j'ai eu aussi des soucis avec puppet ( ainsi qu'une paire de gens sur le canal #puppet ).
Et l'astuce sur le blog mozilla n'a pas marché tel quel chez moi, j'ai du rajouter LC_ALL=C :
service ntpd stop ; date -s "$(LC_ALL=C date )"
[^] # Re: Ne pas oublier LC_ALL=C
Posté par hindy . Évalué à 4.
Je confirme avoir rencontré aussi le problème sur des serveurs en production (Java et MySQL).
Pour ma part j'ai fais les commandes suivantes :
/etc/init.d/ntpd stop ; unset LANG ; date -s "
date"Le load average devrait baisser très rapidement.
Merci pour l'information !
[^] # Re: Ne pas oublier LC_ALL=C
Posté par bubar🦥 (Mastodon) . Évalué à 2.
Comme quoi, heure != temps :-))
ça me fait penser à un plasma qui donnerait une incrémentation sur une fluctuation de ticks depuis le big bang comme indicateur de l'heure, heu pardon, du temps
[^] # Re: Ne pas oublier LC_ALL=C
Posté par ymorin . Évalué à 2.
De mon côté, ce sont firefox et g15daemon qui sont partis en cahouettes…
Hop,
Reboot.
[^] # Re: Ne pas oublier LC_ALL=C
Posté par mike.simonson . Évalué à 1.
Merci pour la solution qui a effectivement fonctionné chez moi.
Maintenant j'ai deux questions.
1 Y a-t-il une solution qui ne nécessite pas d'intervention manuelle pour la prochaine seconde intercalaire? Ou on va devoir à nouveau intervenir manuellement.
2 Pourquoi sur mes 3 serveurs MySql n'y en avait-il que 2 qui étaient touché ?
- Même OS/version pour les 3 serveurs mais hardware différents.
- Le 3ème serveur est identique hardware et OS/version qu'un des 2 serveurs touché.
Merci pour les infos.
[^] # Re: Ne pas oublier LC_ALL=C
Posté par NilugeKiWi . Évalué à 4.
C'est un bug du noyau linux, pour la prochaine seconde intercalaire le fix sera déployé à peu près partout.
[^] # Re: Ne pas oublier LC_ALL=C
Posté par feth . Évalué à 3.
J'ai un peu d'angoisse pour mes debian stable.
[^] # Re: Ne pas oublier LC_ALL=C
Posté par Spack . Évalué à 5.
2.6.32 étant un noyau maintenu sur le long terme je pense que l'on verra vite arriver un
backportrétro-portage de la correction.# Récurent
Posté par pamputt . Évalué à 10.
Bonjour, j'imagine que ce n'est pas la première fois que des secondes sont ajoutées. Et donc à chaque fois qu'une seconde est ajoutée tout se met à dérailler. Vu que ce phénomène est connu, pourquoi les développeurs de trucs très utilisés en environnement serveur comme le noyau linux, mysql, … n'ont ils pas un moyen de prendre en compte cette seconde ? Y-a-t'il une difficulté particulière pour que ça ne soit pas pris en charge ?
[^] # Re: Récurent
Posté par bubar🦥 (Mastodon) . Évalué à -3. Dernière modification le 01 juillet 2012 à 13:08.
Je crois que la réponse est FUCK!
Il est possible (ce n'est qu'une hypothèse personnelle) que les gens réalisant ce type de programmes aient raison : ce n'est pas eux de palier à une déficience fondamentale de notre système de représentation de l'heure. Parcequ'il s'agit ni plus ni moins de cela : des méthodes de représentation de l'heure, et dans des référentiels variés, mais toujours basées sur le «human readable» alors qu'un programme a besoin d'une précision (parfois atomique) sur une cadence, ce qui n'est pas exactement la même chose (c'est juste complémentaire) d'une précision sur l'heure. Temps != heure.
En gros, cela reviendrait à demander à des satellites de fonctionner avec une heure terra-terrienne, et dans un référentiel bancal, pour "faire une synchro plus facile avec l' horloge dans la barre de tache du pc". Bref, le problème semble plus vaste (et plus "philosophique") qu'un simple "ben implémentons un hack" ;-))
[^] # Re: Récurent
Posté par bubar🦥 (Mastodon) . Évalué à -1.
L'heure étant un référentiel, le temps étant la cadence.
À partir du moment où l'heure change, c'est le référentiel de la cadence qui change.
Et cette heure, «human readable» est elle même basée sur un référentiel : utc, gmt+n, etc… eux mêmes tous basés sur un autre référentiel : la rotation de notre système solaire. Bref, tout ça ne passera pas à l'échelle, bientôt, c'est bien trop petit bras… /humour : il temps de prendre l'heure sur l'estimation sans cesse changeante de la date du big-bang :p
[^] # Re: Récurent
Posté par barmic . Évalué à 10.
Non si un processus pour une raison où une autre se met à consommer plus de CPU c'est un bug. Que les développeurs soit d'accord ou pas avec le système de représnetation de l'heure ne change pas ce fait. Etre fiable (ce que veulent des appli comme le noyau, le JVM ou MySQL) ce n'est pas annoncer fierement que l'on ne veut pas gérer un cas et donc qu'il arrivera ce qu'il arrivera (comme si ce n'était pas le problème du développeur).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Récurent
Posté par Jux (site web personnel) . Évalué à 8.
D'autant plus qu'il me semble qu'il est possible que l'heure d'un système informatique "saute" de quelques secondes (ou revienne un peu en arrière) pour une raison ou pour une autre. Ca doit d'ailleurs arriver relativement souvent si on synchronise l'heure système avec un serveur central, non ? Ces logiciels ne gèrent-ils pas ces cas-là ?
[^] # Re: Récurent
Posté par Patrick Lamaizière (site web personnel) . Évalué à 5.
Ben non l'horloge est ajustée en l'accélerant ou en la ralentissant, mais il faut éviter les sautes brusques. Y'a des logiciels qu'ont horreur de ça (par exemple make dans le cas d'un retour dans le temps)
les pixels au peuple !
[^] # Re: Récurent
Posté par fabien . Évalué à 1.
ha bon,quand on change l'heure de sons systeme, il change la frequence ?
si on retire une minute (on regle l'heure quoi, a coup de date ou par ntp) alors les secondes vont s'ecouler plus lentement pour arriver à l'heure demandée ? c'est curieux, je n'avais jamais entendu ce truc là… et ca me semble peu probable (au dela de quelques milli-secondes)
ntp fonctionnerai ainsi ?
je suis septique
[^] # Re: Récurent
Posté par feth . Évalué à 3.
http://www.akadia.com/services/ntp_synchronize.html
C'est un algorithme d'ajustement non trivial d'ailleurs, du coup je ne sais pas l'expliquer :-)
[^] # Re: Récurent
Posté par barmic . Évalué à 6.
Non
Oui
C'est la synchronisation ntp qui fonctionne comme ça. si avec la commande date tu change l'heure du système ça se fait de manière directe.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Récurent
Posté par fabien . Évalué à 5.
ok,
bon alors la question bête : puisque ca ne plante pas tout quand on fait un simple date, pourquoi ntp ne fonctionne pas en faisant un simple date ?
j'avais prévenu, c'est bête hein…
[^] # Re: Récurent
Posté par gouttegd . Évalué à 2. Dernière modification le 02 juillet 2012 à 01:06.
Qui te dit que « ça ne plante pas tout » quand on fait un simple date ?
Certains programmes ne supportent pas que l’heure du système change brutalement. Le cas de make a déjà été cité, il y a aussi Dovecot par exemple, qui s’arrête immédiatement avec un Time moved backwards error.
Quand l’administrateur met à jour l’heure manuellement avec date, ce n’est pas forcément très grave : si l’administrateur est présent pour exécuter date, il est aussi présent pour vérifier si des programmes ont été interrompus, et les relancer le cas échéant.
Mais avec ntpd qui peut avoir besoin de corriger l’heure à tout moment, un changement brutal à la manière de ce que fait date doit être évité, d’où l’approche par ajustements successifs — qui, en temps normal, ne fait rien planter du tout, sauf quand il y a justement un bug dans la gestion des secondes intercalaires…
[^] # Re: Récurent
Posté par 2PetitsVerres . Évalué à 4.
Parce que ce n'est pas un changement de date, mais qu'il y a une seconde en plus, on ne va pas la passer sous silence quand même !
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Récurent
Posté par calandoa . Évalué à 0.
Et surtout, si NTP est capable de faire un changement d'heure en loucedé ni vu ni connu je ralentis discrètement l'aiguille des seconde, pourquoi on ne ferait pas ce rajout de leap seconde par le même système, plutôt que d'obliger tous les développeurs à gérer des minutes de 61 secondes ? (ce qui est totalement crétin… heureusement que le con qui nous a trouvé ce workaround s'est arrêté là et ne nous a pas pondu des octets qui parfois peuvent aller jusqu'à 257)
[^] # Re: Récurent
Posté par Zenitram (site web personnel) . Évalué à 10. Dernière modification le 02 juillet 2012 à 11:47.
Ce n'est pas crétin : cette 61è seconde existe vraiment.
NTP peut tricher et "ralentir le temps" mais ton référentiel est alors pourri. Ca peut plaire à Google qui s'en foutrait du temps à la seconde près, mais si c'est un timestamp précis que tu veux utiliser NTP pour ralentir te flingue juste ton timestamp.
Les développeurs doivent gérer cette 61è seconde car elle existe.
Si tu bidouilles avec NTP pour ralentir, ta marge d'erreur serait de plus d'une seconde.
Certains peuvent accepter cette marge, pas d'autres. Comment tu sais à l'avance? Pourquoi mettre par défaut sur ton système l'heure non officielle plutôt que l'heure officielle? Après, certes, on peut décider par choix d'envoyer chier les gens pour qui la précision est importante, et leur dire de patcher leur système si ils ont besoin d'un horaire précis… On peut aussi trouver totalement crétin de compter en années/jour/heure/minutes/secondes, et compter que les secondes depuis le 1er Janvier 1970. C'est un choix à faire. Mais quelle idée de diviser par 60, 24, 365 (et en plus, ils font chier avec leur jour intercalaire, virons-le et NTP fera la transition douce sur le serveur. Rigole pas trop, ce que tu dis c'est comme lisser une journée, certes moins visible car la seconde est petite, mais cette seconde n'est pas petite pour tout le monde).
Bref, les informaticiens galèrent avec l'heure d'été/d'hiver (perso, je suis plus pour virer l'heure d'été/d'hivers qui fait bien plus chier les dévelopement, même sur un iPhone, et qui ne sert pas à grand chose), les mois qui ne font pas tous 30 jours, cette 61è seconde n'est qu'un détail d'implémentation comme un autre sur le temps.
[^] # Re: Récurent
Posté par calandoa . Évalué à 2.
Euh, la « seconde qui existe vraiment », c'est une explication qui ne veut rien dire. C'est les humains qui décident de comment appeler les choses, qu'il décident d'appeler « minute » 61 secondes, ou « seconde », 999/1000 d'une seconde habituelle (cf UTC-SLS plus bas que je viens de découvrir), ça ne change rien à ce qui existe ou non.
Concernant le ralentissement du temps, ça peux effectivement gêner certains (par exemple des gars qui s'amuseraient à mesurer la vitesse de neutrinos et qui s'emporteraient pour rien à cause d'un problème de mesure), mais de toute façon, comme dit plus haut, c'est ce qui se passe effectivement sur les systèmes normaux à chaque synchro de NTP, alors, un ralentissement de plus ou de moins, si on a la possibilité de le désactiver pour les rares personnes que ça dérangerait, ça me parait moins compliqué que d'aller expliquer à tous les développeurs de la terre qu'ils doivent gérer ce cas là.
Sur les autres problèmes de temps, ça n'est pas la question : on peut virer ou non l'heure d'été, tant mieux ou temps pire, ça ne change pas le problème de la seconde. D'ailleurs, sur la journée intercalaire, on ne pas appliquer cette technique, sinon, au cours des journées précédentes, le soleil serait décalé par rapport à l'heure. Et si on l'ignorerait, on se retrouverait avec noël en plein été. Pour la petite histoire, lorsque le pape Grégoire X (pas 10, X pour je ne sais plus) à imposé son calendrier, il a zappé d'un coup le décalage accumulé en divisant la durée du mois courant par deux ! ce qui a eu des conséquences assez tordues sur la vie courante des gens : comment vous faites lorsque votre proprio vous réclame un loyer complet et que votre patron ne vous paie qu'un demi salaire ?
[^] # Re: Récurent
Posté par Zenitram (site web personnel) . Évalué à 3.
Pour corriger la merde d'horloge sur ta machine. Si elle dévies d'une seconde, tu as une sacrée pourriture d'horloge. Ca corrige un problème local. ici, on veut "corriger" un problème global, s'en faire attention à comment l'être humain a décidé.
Exactement, et la solution par NTP va carrément violer l'accord commun des humains.
Pour le dire autrement : si je veux tes logs Apache (bon, faudrait trouver un exemple plus précis qu'Apache certes) entre 23:59:60.000 et 00:00:00.000, tu fais comment pour le fournir si tu as pourris ton système en supprimant cette seconde réelle dans le révérenciel humain?
Exactement le même argument qui a fait que l'être humain a mis la seconde intercalaire en oeuvre, tient!
[^] # Re: Récurent
Posté par calandoa . Évalué à 1.
Excuse moi, je n'ai pas du être clair : le bit de la manœuvre, c'est de raccourcir ou rallonger les secondes pour ne plus avoir de 23:59:60. Donc tu peux inventer des contre exemples, mais sans 23:59:60, car justement ce moment n'a plus lieu d'être.
Alors effectivement, il faudra bien raccourcir ou rallonger quelque chose, mais le faire sur des unités plus petites que la seconde, ça permet de ne pas perturber les activités humaines qui, dans le plus grand nombre de cas, s'en tiennent à la seconde au plus précis.
« Exactement le même argument qui a fait que l'être humain a mis la seconde intercalaire en oeuvre, tiens ! »
Si tu rallonges les 1000 dernières secondes avant minuit, tout le monde n'y voit que du feu. Si tu rallonges les 100 derniers jours avant le 28 février, ben le jour -50, il fera grand soleil à minuit.
(franchement, ça serait pas mal si tu pouvais te retenir de poster un message tous les 61 et passer 1001/1000 secondes de plus à réflechir un peu plus à chacun)
[^] # Re: Récurent
Posté par barmic . Évalué à 10.
J'ai pleins d'amis qui m'envoie des mails tout les jours et qui ont une idée très précise de ce qu'il faudrait rallonger.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Récurent
Posté par oinkoink_daotter . Évalué à 3.
Lui aussi je pense /o/ -->
[^] # Re: Récurent
Posté par Thomas Debesse (site web personnel) . Évalué à 9.
Et les humains fournissent [par l'intermédiaire de machines] des services pour les humains.
Par exemple, je travaille pour une radio. Cette radio fait partie d'un réseau national de radios locales. Nous avons un calendrier précis de balises, ces balises sont des secondes de silence pendant lesquelles ont peut raccrocher ou décrocher c'est à dire passer d'un programme (national par exemple) à un autre programme (local). Dans notre radio nous avons la particularité d'avoir deux programme locaux, parfois communs, parfois dissociés.
Tout ça est donc géré à la seconde près. Il faut que nous décrochions ou raccrochions, c'est à dire commencions ou terminions nos émissions à la même heure et même minute et même seconde que l'autre programme commence ou termine, en même temps que nous basculions les sources sonores. Lorsque nous décrochons en local il y a toujours du son sur le national vu que d'autres radio locales ne décrochent pas forcément à cette balise là, mais à d'autres. Parfois certains décrochages se font manuellement (émission en direct, par exemple).
Il faut donc que le système de gestion du temps utilise le temps des humains. Nos automates utilisent les secondes humaines, pas le temps Unix ou que sais-je. Quand je prends la balise de 17:59:01, je prends 17:59:01, que j'ai eu une minute de 60s ou de 61s dans la nuit qui a précédé.
C'est un homme qui écoute la radio, c'est donc à sa perception humaine de l'heure que nos machines doivent se plier.
L'auditeur a une grille de programme dans la main, ce programme est un calendrier humain.
Si le programme national gère la 61ème seconde mais pas le local, ou l'inverse, alors à chaque balise on peut se retrouver avec une seconde d'émission parasite. C'est dégueu !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Récurent
Posté par calandoa . Évalué à 0.
…ce qui est le cas avec le système actuel ! Certains systèmes ont respecté la leap second, d'autres non. Alors que si on étalait les 1000 dernières secondes, et bien on tomberait… euh… dans le même cas. Tu essayes de dire quoi en fait ?
[^] # Re: Récurent
Posté par Thomas Debesse (site web personnel) . Évalué à 8. Dernière modification le 02 juillet 2012 à 17:05.
Tu as dit
Que ça existe ou non, les machines fournissent des services pour des humains.
Si les humains ont dit "il y aura 61 secondes telle minute du 30 juin 2012", il faut que la machine fasse en sorte que cette minute dure 61 secondes et non 60. La machine est au service de l'humain même si cet humain est complètement tordu.
C'est l'homme qui a décidé ce qu'était une seconde, comme tu les dis, et c'est justement pour cela qu'il peut aussi définir des minutes de 61 secondes.
Le temps existe sans l'homme, mais la seconde ou la minute n'existent que parce que l'homme les ont définies.
Cette seconde intercalaire existe parce que l'homme l'a défini. Si ta machine rajoute un millième de seconde toutes les secondes pendant 1000 secondes, ta machine arrive au même instant que la machine qui a compté 61 secondes la dernière minute, mais son comptage est erroné : elle a compté une seconde de moins. Elle sonne minuit au même instant mais elle n'a pas compté le nombre de secondes voulu et défini par l'homme, elle est donc défectueuse.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Récurent
Posté par 2PetitsVerres . Évalué à 7.
Tu parles de deux groupes de gens différents là. Les scientifiques et les journalistes, respectivement pour la première et la deuxième partie de ta phrase.
Moins compliqué, peut-être (sauf pour ceux qui veulent le vrai temps), mais faux. Et si les développeurs lisaient la doc, ils seraient au courant. Par exemple dans ctime(3) :
Je suis sûr que la doc java dit pareil.
Il y a un pays qui a changé récemment de fuseau horaire et qui a perdu un jour (un vendredi je crois) en traversant la ligne de séparation de jour (pour être le premier à fêter le nouvel an et pour être au même jour que ses partenaires commerciaux) Ce genre de détail était réglé la loi. (du genre les banques devaient payer des intérêts complets pour un mois, …)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Récurent
Posté par calandoa . Évalué à 7. Dernière modification le 02 juillet 2012 à 15:11.
« Et si les développeurs lisaient la doc, ils seraient au courant »
C'est bien la le problème. Déjà qu'une solution qui exige que les développeurs écrivent de la doc est vouée à l'échec, une solution qui exige que les développeurs lisent de la doc, c'est malheureusement impossible.
[^] # Re: Récurent
Posté par Thomas Debesse (site web personnel) . Évalué à 7.
Tout à fait, ce qui fait que Thérèse_d'Avila est morte dans la nuit du jeudi 4 au vendredi 15 octobre 1582 (et c'était le pape Grégoire XIII, le X n'était pas loin ;).
En l’occurrence, ce n'est pas très problématique d'être payé un demi salaire puisque vous avez réellement travaillé un demi mois. Si tu es payé à l'heure, cela ne pose aucun problème. Tout ça ce sont des questions légales, comme l'a écrit 2ptitsverres : ça se résout par la loi.
(et juste pour le goût du troll, le calendrier grégorien a donc été imposé par un pape catholique en 1582. Le calendrier grégorien est un calendrier solaire, c'est à dire qu'un pape catholique a imposé de calculer les dates en partant du principe que la terre tourne autour du soleil. À cette époque, Galilée avait 18 ans. Les attaques contre Galilée commenceront vraiment autour des années 1610, il avait donc plus de 45 ans, et Galilée fut condamné en 1633 (69 ans). Lorsqu'il fut condamné, cela faisait déjà 51 ans que ses détracteurs calculaient leurs jours selon la rotation de la terre autour du soleil, certains n'avaient peut-être même pas connu autre chose qu'un calendrier héliocentrique. Était-ce une attaque scientifique, religieuse, ou n'était-ce pas plutôt une attaque personnelle qui a instrumentalisé la science et la foi ?)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Récurent
Posté par CHP . Évalué à 5.
J'ai du mal à voir d'où tu tires la relation entre calendrier solaire et heliocentrisme. Ne peut-on pas avoir un calendrier basé sur le mouvement apparent du soleil dans le ciel tout en pensant que c'est lui qui tourne autour de la terre ?
Ceci est une vraie question.
[^] # Re: Récurent
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
C'est peut-être pour ça que ça n'a pas trop dérangé les détracteurs de Galilée : il suffit de faire le grand écart en disant que le calendrier est solaire parce que c'est un modèle pratique sans nécessairement reconnaitre l'héliocentrisme.
Cependant, il apparait que Copernic a travaillé sur un premier travail de réforme du calendrier sous Léon X, travaile que Grégoire XIII relancera et terminera. Cette réforme du calendrier est donc difficilement dissociable du système copernicien.
C'est donc autant plus étonnant de constater que le système copernicien qui a servi à l'élaboration (Léon X) du calendrier (Grégoire XIII) fut censuré en 1616 (pape Paul V), ce qui donnera prétexte aux détracteurs de Galilée et donnera matière à sa condamnation (Urbain VIII) il n'est pas condamné pour sa position scientifique mais pour ne pas respecter une décision de justice.
Petite frise chronologique papale :
Wikipédia précise :
Sources :
https://fr.wikipedia.org/wiki/Passage_au_calendrier_gr%C3%A9gorien
https://fr.wikipedia.org/wiki/Copernic
https://fr.wikipedia.org/wiki/Galil%C3%A9e_%28savant%29#La_censure_de_la_th.C3.A8se_copernicienne_.281616.29
https://fr.wikipedia.org/wiki/Liste_des_papes
http://366jours.free.fr/articles.php?lng=fr&pg=1018
Note : à l'époque on changeait souvent de Pape !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Récurent
Posté par 2PetitsVerres . Évalué à 10.
Et donc tu penses que faire de minutes de 61 secondes c'est crétin, mais tu proposes de faire des secondes qui ne valent pas la durée de 9 192 631 770 périodes de la radiation correspondant à la transition entre les niveaux hyperfins F=3 et F=4 de l’état fondamental 6S½ de l’atome de césium 133 ? C'est au moins aussi crétin.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Récurent
Posté par barmic . Évalué à 10.
Il me semble important de préciser que c'est un atome de césium au repos, à une température de 0 K (sinon c'est trop flou comme mesure… :D
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Récurent
Posté par wismerhill . Évalué à 4.
Le problème, c'est qu'il est impossible d'atteindre 0K…
[^] # Re: Récurent
Posté par riba . Évalué à 5.
Le problème c'est surtout que la température d'un seul atome ne veut rien dire.
[^] # Re: Récurent
Posté par barmic . Évalué à 6.
Je vous recommande d'aller voir le site du SI : http://www1.bipm.org/fr/si/si_brochure/chapter2/2-1/second.html
Il donne une réponse à vos deux questions :
Donc non on ne peut pas atteindre 0 K, mais il faut le prendre en compte.
Oui 0 K, n'a pas de sens d'un point de vu thermique, mais il permet d'exprimer l’absence de rayonnement (du moins c'est ce que je comprends).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Récurent
Posté par neil . Évalué à 4.
Il y a quand même une différence entre sauter d’heure et être à 23:59:60.
[^] # Re: Récurent
Posté par Larry Cow . Évalué à 2.
Sinon, on peut "juste" être à 23:59:59 pendant deux secondes d'affilée.
[^] # Re: Récurent
Posté par windu.2b . Évalué à 6.
C'est un coup à pourrir tous les systèmes ayant recours à des mesures dans un intervalle de temps ("est-on dans la 1° ou la 2° seconde de 23:59:59 ?"), comme la mesure de la vitesse, par ex.
[^] # Re: Récurent
Posté par wismerhill . Évalué à 3.
C'est pire pour le passage de l'heure d'été à l'heure d'hivers où on a toute une heure de recouvrement.
Ça c'est une belle connerie.
[^] # Re: Récurent
Posté par Zenitram (site web personnel) . Évalué à 3.
Pas du tout : été ou hiver, ton heure UTC n'a aucun recoupement, c'est facile. Après, si tu t'amuses à faire tes calculs en heure locale…
[^] # Re: Récurent
Posté par wismerhill . Évalué à 1.
Quand je regarde dans les logs des serveurs, il n'est pas écrit si il est 2h du matin pour la première fois ou la deuxième, et cron n'est pas informé non plus et lance gentiment deux fois (ou pas du tout dans le cas contraire) les tâches que j'avais fait l'erreur de programme entre 2h et 3h.
[^] # Re: Récurent
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 02 juillet 2012 à 22:13.
Comme déjà dit : "Après, si tu t'amuses à faire tes calculs en heure locale…"
Les miens de logs justement sont en… UTC. Je ne sais pas comment on peut imaginer des logs Apache sans UTC, ou quitte à changer au minimum l'horodatage en format ISO contenant le fuseau horaire (qui fait que tu saurais si c'est la première au deuxième fois). Parait que les linuxiens trouvent ces logs bien alors que le format de l'horodatage est des plus bizarres, je vais dire que je survis avec et que je n'ai pas le courage de passer du temps à mettre les logs à un format correct (format ISO), je demande la chose en UTC c'est le "moins pire" et j'ai la flemme de chercher si c'est faisable d'avoir un format ISO (je ne m'en sert pas assez pour trouver ça utile, mais pour une personne pour qui c'est le métier…).
Pour cron, il me semble qu'il se débrouille pas trop mal avec les configs "locales" de souvenir (il ne répète pas deux fois, et ne saute pas de taches lors du passage inverse) mais je ne suis pas sûr, je délègue un max cette partie donc j'oublie les détails.
[^] # Re: Récurent
Posté par BAud (site web personnel) . Évalué à 5.
eh ! une chance de battre le record du 100 m !
[^] # Re: Récurent
Posté par 2PetitsVerres . Évalué à 1.
Avec une seule seconde supplémentaire, ça risque d'être dur quand même.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Récurent
Posté par ymorin . Évalué à 10. Dernière modification le 01 juillet 2012 à 13:12.
En effet, ce n´est pas la première seconde intercalaire qui soit ajoutée.
Cependant, le bug n´est pas systématique. Le message de commit dans les liens dit :
Le changement pour utiliser un
hrtimerdate de Mai 2008. Hormis cette nuit, la dernière seconde intercalaire ajoutée date de Décembre 2008. Donc, il n'y a pas eu tant de cas où ça a pu dérailler : un seul au total, qui a pu passer inaperçu.Le cas d'hier aurait pu être évité si les systèmes avaient mis leur noyau à jour, car le correctif date de Mars dernier. Pour les systèmes dont le noyau n´était pas à jour, il y a donc eu un second cas hier soir.
Hop,
Moi.
[^] # Re: Récurent
Posté par bubar🦥 (Mastodon) . Évalué à -3.
et merde … :-)
[^] # Re: Récurent
Posté par Pierre Carrier . Évalué à 2.
Non. Le kernel de mon ordinateur portable était à jour et MySQL a bien pris 100% de CPU.
Mon employeur a anticipé, coupé tous les ntpd et retiré la leap second a l'aide d'un petit binaire.
Quelques services n'ont pas reçu cette correction par erreur (oubli d'un réseau pas publiquement addressable) et ont systématiquement eu des problèmes (JVM principalement). Mais le gros de la production a parfaitement survécu.
Google de leur côté trichent avec UTC-SLS ( http://www.cl.cam.ac.uk/~mgk25/time/utc-sls/ ), et ils ont bien raison :)
Gros coup de stress peu après minuit GMT, surtout quand on surveillait Twitter et découvrait qu'un tas de gros services étaient tombés (dont yelp.com, Facebook XMPP, etc.).
[^] # Re: Récurent
Posté par Maclag . Évalué à 7.
Unix n'a pas le bug. C'est la lecture du temps qui pose problème.
Il est 1341145622
# Java & mysql
Posté par ß ß . Évalué à 8.
Encore un coup de canif d'Oracle dans le ventre du libre !
[^] # Re: Java & mysql
Posté par ashgan . Évalué à 1.
ca ne serait pas plutôt lié a l'arrêt du minitel?
moi, j'y vois une belle coïncidence…
# Pourquoi ne pas avoir fait ça le 28 octobre ?
Posté par xavier dumont . Évalué à 2.
Au lieu de retarder les horloges de 60 minutes ( pour passer à l'heure d'hiver ), il aurait suffi alors de les retarder de 59 minutes, 59 secondes. On aurait eu 1 seconde d'avance pendant 6 mois et pis c'est tout.
En plus les ordis, ils se mettent tout seuls à l'heure d'hiver, non ?
[^] # Re: Pourquoi ne pas avoir fait ça le 28 octobre ?
Posté par Frédéric Péters (site web personnel) . Évalué à 6.
Je dirais que c'est simplement parce que tous les pays ne passent pas (et à la même date, encore moins) à l'heure d'hiver.
[^] # Re: Pourquoi ne pas avoir fait ça le 28 octobre ?
Posté par Zenitram (site web personnel) . Évalué à 5. Dernière modification le 01 juillet 2012 à 14:31.
Tu mélanges deux choses :
- l'heure UTC
- l'heure locale
L'heure d'hiver (d'été plutôt), c'est ton heure locale qui change, dans le système absolument rien ne change, c'est que de l'affichage (si ton serveur est en UTC, tes logs sont même en UTC).
En pus, c'est quoi le 28 octobre? Pour la majorité de la planète, absolument rien. Pour l'Europe, c'est peut-être quelque chose, mais l'Europe n'est pas le centre du monde. Rappel : le choix de la date de changement d'heure, quand il y a une date, est différente suivant les régions du monde.
Ici, c'est l'heure UTC qui a changé (mais pas l'heure GPS, attention ;-). Le time code GPS contient toutefois une info sur le décalage par rapport à UTC). et pour l'heure UTC, le 28 octobre est rien du tout sur toute la planète.
Bref, rien à voir, choisir cette date serait même pire pour débugger (tu ne sais pas si le problème vient de l'heure UTC comme ici ou de l'heure locale qui a changé)
[^] # Re: Pourquoi ne pas avoir fait ça le 28 octobre ?
Posté par JGO . Évalué à 3.
Les secondes intercalaires s'appliquent entre le temps atomique international (TAI) et le temps universel coordonné (UTC), alors que l'heure d'été s'applique entre l'UTC et le temps local, ce sont deux concepts différents qui répondent à des objectifs différents.
Le passage de UTC au temps local est un gros bordel : tous les pays n'appliquent pas l'heure d'été, et tous les pays ne l'appliquent pas le même jour, certains pays ont changé plusieurs fois d'idée, d'autres plusieurs fois de date.
Pour les secondes intercalaires, on a un système clair et simple, dont l'entropie est seulement de 2 bits d'information par an. Les utilisateurs du TAI peuvent très facilement déterminer, pour chaque date passée, la différence en secondes avec l'UTC, car les changements se font à date fixe. Faire le changement à date variable (parfois le 28 octobre, parfois le 30, etc.) n'apporterait aucun bénéfice pour la population (qui n'est pas informée des secondes intercalaires) mais compliquerait le travail de ceux qui ont besoin de la conversion TAI/UTC.
Ils se mettent tout aussi automatiquement à l'heure de la seconde intercalaire s'ils sont connectés à internet. S'ils ne sont pas connectés, la différence d'une seconde n'a aucun impact pratique, la précision des puces usuelles (DS1307 et ISL1206) étant d'une minute par mois à 20 °C.
[^] # Re: Pourquoi ne pas avoir fait ça le 28 octobre ?
Posté par claudex . Évalué à 3.
Il me semble qu'au Brésil, la date de changement d'heure est votée chaque année par province (en pratique, c'est toutes les provinces en même temps mais ça pourrait être complètement différent).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pourquoi ne pas avoir fait ça le 28 octobre ?
Posté par claudex . Évalué à 3.
Je pense que ça aurait été plus compliqué, parce que le changement d'heure, c'est juste un changement de fuseau horaire. Si on doit adapter les fuseau horaires pour qu'ils fonctionnent à la seconde près pour un truc qui se fait tout les 4 ans, ça risque de faire beaucoup de boulot pour pas grand chose.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# J'ai rien senti !
Posté par Christophe Merlet (site web personnel) . Évalué à 2.
C'est ça ta "leap second" ?
Chez moi elle a eu lieu samedi à 18h ! A part ça rien…
[^] # Re: J'ai rien senti !
Posté par Zenitram (site web personnel) . Évalué à 3.
Ton serveur ne serait-il pas en heure CST (UTC-6)?
La leap second est mise à 00:00 UTC. Soit 18:00 heure locale centrale américaine.
[^] # Re: J'ai rien senti !
Posté par Christophe Merlet (site web personnel) . Évalué à 4.
Dernière mise à jour du graphique : dimanche 1 juillet 2012 à 15h15m08s
Date du commentaire : 01/07/12 à 15:24
Manifestement le graphique est à l'heure française (UTC+0200)…
# Et en français
Posté par Papey . Évalué à 10.
Notre langue est tellement riche qu'on a même une expression pour « leap second ». Je sais, ça paraît fou ! On nomme une telle seconde « seconde intercalaire » ou « seconde additionnelle ». Rêvons un instant : encore un effort et on pourra carrément faire des journaux complets sans emprunter d'expressions à d'autres langues quand on n'en a pas besoin.
[^] # Re: Et en français
Posté par ckyl . Évalué à -2.
Bha écris le la prochaine fois…
[^] # Re: Et en français
Posté par Prae . Évalué à 9.
C'est la variante de "proposes un patch ou fermes-là" ?
[^] # Re: Et en français
Posté par ckyl . Évalué à 2.
Oui elle se nomme: Je préfère les gens qui ont des choses à dire plutôt que ceux qui n'ont que des critiques sur la forme à faire.
[^] # Re: Et en français
Posté par BAud (site web personnel) . Évalué à 7.
Un intérêt de parler de « leap second » c'est que cela permet de lancer une recherche pertinente sur la lkml :
http://www.google.fr/search?q=lkml+leap+second en second lien on tombe sur https://lkml.org/lkml/2012/6/30/122 par exemple
En revanche, si l'on souhaite augmenter la pertinence des recherches pour ceux qui la lancent en français (et pour ceux qui lisent le français), il est plus intéressant de parler de seconde intercalaire
http://www.google.fr/search?q=lkml+seconde+intercalaire (ce journal est actuellement premier sur les résultats).
C'est une question de compromis et d'utilisation des termes appropriés selon le contexte.
# buildbots Python
Posté par Antoine . Évalué à 2.
Et sur les buildbots Python, une des machines a commencé à avoir des erreurs de test bizarres (et même un crash) après la leap second :
# Pour les non connaisseurs ?
Posté par tuxg . Évalué à 10.
Quelqu'un pourrait il m'expliquer le problème ?
Pourquoi les applications ne continuent pas de fonctionner normalement, avec une seconde de retard ?
[^] # Re: Pour les non connaisseurs ?
Posté par NilugeKiWi . Évalué à 1.
En l'occurrence le bug qui se manifeste par java/mysql/firefox/thunderbird/etc à 100% de cpu est dans le noyau linux:
https://lkml.org/lkml/2012/7/1/203
https://lkml.org/lkml/2012/7/1/176
Après il y a potentiellement en plus des bugs par application sur la minute avec 61 secondes.
# Merci, je me coucherais moins con ce soir
Posté par Framasky (site web personnel) . Évalué à 2.
Je ne voyais pas pourquoi mon serveur était à 16 de load (sur un petit atom d'un kimsufi, ouch !) quand je me suis levé ce matin, mais du coup je comprends mieux. J'avais bien vu que c'était subsonic qui fichait le bazar, mais je m'étais dit que c'était normal, c'est du java. J'avais raison.
Par contre la base mysql ne consomme pas plus que d'habitude.
Merci pour l'info.
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
# Il existe vraiment ce bug ?
Posté par ondex2 . Évalué à -2.
Il existe vraiment ce bug ?
Parce que sur quelques dizaines de serveurs, des centaines de VM dont certaines pas du tout à jours (il y a encore une ou deux Debian Sarge qui trainent), des équipements SAN et réseau, rien dans la supervision, rien dans la métrologie non plus…
Je dormirai tranquille cette nuit, on verra demain matin si j'ai eu raison…
[^] # Re: Il existe vraiment ce bug ?
Posté par Christophe Merlet (site web personnel) . Évalué à 2.
Je viens de voir que sur un autre serveur j'ai eu ça…
J'ignore quelle est le processus qui a fait des siennes…
[^] # Re: Il existe vraiment ce bug ?
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Moi je l'ai eu sur une bécane, sur un vieux service proprio usé par tout les bouts mais malheureusement irremplaçable. Évidemment je ne l'ai vu qu'au réveil… et remettre tout ça en état m'a fait rater la messe !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Il existe vraiment ce bug ?
Posté par barmic . Évalué à 3.
Il faut utiliser ntp pour avoir le bug, ce n'est pas toujours le cas par défaut.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Il existe vraiment ce bug ?
Posté par gnumdk (site web personnel) . Évalué à 2.
Ben moi, j'ai des erreurs de connection ntp (ntpdate dans crontab) sur le routeur cisco mais c'est tout. Quand un service par en couille, ca pourrait se corriger tout seul ?!?
[^] # Re: Il existe vraiment ce bug ?
Posté par Maclag . Évalué à 6.
Ben moi j'ai bien ntp, mysql, sur mon PC de bureau, et il ne s'est rien passé.
Pourtant il commence à joyeusement planter quand il chauffe un peu.
Et là il ne se passe absolument ri
[^] # Re: Il existe vraiment ce bug ?
Posté par shbrol . Évalué à 0.
Pourtant les bugs mentionnés ne concernent pas les clavier qui se blo
[^] # Re: Il existe vraiment ce bug ?
Posté par Krunch (site web personnel) . Évalué à 3.
Justement, les kernels « très » vieux (Sarge et RHEL 5 par exemple) ne sont pas affectés. Comme dit dans le commit, le bug a été introduit dans mainline en mai 2008.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Précisions
Posté par Yannick (site web personnel) . Évalué à 8.
Deux de choses, l'une : La Terre tourne sur elle-même en 23 heures 56 minutes et 4 secondes. Ceux qui disent "24h" parlent en fait de la durée du jour, car pendant que la terre tourne sur elle-même, elle tourne aussi autour du soleil. Le soleil n'est donc plus tout a fait à la même place à la rotation suivante. Et il y a 4 petites minutes à rattraper (soit 24/365.25).
Deuxième point : La Terre n'a pas une vitesse de rotation parfaitement constante. Ce qui fait qu'on remarque un décalage entre le temps très précis des horloges atomiques et le temps terrestre (calé sur la position du soleil dans le ciel). Pour garder une synchronisation entre l'heure atomique et la position du soleil dans le ciel, et ne pas se retrouver avec un 12h00 atomique à 17h56 UTC à Greenwich, on ajoute ou retire une seconde si nécessaire, tous les six mois, en fonction du décalage constaté. C'est ce qui c'est passé ce week-end. Cette seconde s'appelle une seconde intermédiaire.
[^] # Re: Précisions
Posté par Zenitram (site web personnel) . Évalué à -4.
Faux.
Seconde_intercalaire
[^] # Re: Précisions
Posté par Nitchevo (site web personnel) . Évalué à 2.
Merci, je n'arrivais pas à comprendre comment un jour pouvait durer moins longtemps qu'un jour et ainsi ne pas respecter sa propre définition ce qui est assez vertigineux.
[^] # Re: Précisions
Posté par Zenitram (site web personnel) . Évalué à -7. Dernière modification le 02 juillet 2012 à 10:15.
Ca peut arriver, mais ici ce n'est pas le cas : le 30 juin a duré plus (une seconde de plus) longtemps que 24 heures 0 minutes 0 secondes (et non un jour, ça veut rien dire ta phrase cf plus bas).
Quelle "propre" définition? La tienne? La définition exacte d'un jour prend en compte l'évolution scientifique et contient bien cette seconde intercalaire, tout comme la définition d'une année contient bien le 29 février intercalaire lui-aussi : la définition d'année ne respecte pas sa propre définition aussi de ton point de vue?
[^] # Re: Précisions
Posté par claudex . Évalué à 4.
Donc le 29 juin a duré moins longtemps que le 30 juin et un jour a bien duré moins longtemps qu'un jour.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Précisions
Posté par Zenitram (site web personnel) . Évalué à -4. Dernière modification le 02 juillet 2012 à 10:34.
Oui si tu comptes en secondes, non si tu comptes en jours (mais compter en jour est bizarre quand même)
De plus, ça me semble pas très logique de comparer le "normal" à l’exceptionnel, donc je sais pas vous mais moi dans une discussion je compare le 30 juin aux autres jours, le 30 juin a duré plus longtemps. Le tout pour être logique vis à vis d'un interlocuteur.
Énorme.
Un jour (29 ou 30 juin) a duré un jour, ni plus, ni moins : la définition de jour comprend la seconde intercalaire.
Maintenant, on va dire qu'un an ne dure pas un an, juste par que le nombre de jours dans l'année n'est pas le même suivant l'année… Logique des plus bizarre.
[^] # Re: Précisions
Posté par claudex . Évalué à 4.
Un jour (le 29 juin) a bien duré moins longtemps qu'un jour (le 30 juin). Comme cette année a durée plus longtemps que l'année passée.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Précisions
Posté par barmic . Évalué à 5.
Il a juste était surpris que deux jours peuvent ne pas avoir la même durée, c'est quoi le problème ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Précisions
Posté par Zenitram (site web personnel) . Évalué à -5. Dernière modification le 02 juillet 2012 à 11:03.
Je suis peut-être vieux con, mais un jour n'a pas duré plus ou moins longtemps qu'un jour, si on compte en jours. Je suis peut-être vieux con mais qu'on me sorte "ne pas respecter sa propre définition" comme ça brut de fonderie me fait bondir.
Un jour a duré 86401 secondes alors que d'habitude il dure 86400 secondes, certes, mais c'est quoi le problème avec jour? Aucun. tous les jours respectent la définition de jour.
Je réagis sur des détails sans doute… Mais c'est quoi cette manie de tout de suite dire que c'est la définition qui est mauvaise sans se documenter sur la définition en fait? Il n'y a absolument rien de vertigineux.
Pas comprendre, OK, mais balancer que ça ne respecte pas la définition me fait des plus bizarre sur la façon de se poser la question. Surtout qu'une rapide recherche curieuse sur "leap second" (fournit dans le journal) donne immédiatement l'explication.
[^] # Re: Précisions
Posté par barmic . Évalué à 10.
Si on en est à attaquer des drosophiles, il faut y aller vraiment.
Ce document officiel : http://www1.bipm.org/utils/common/pdf/si_brochure_8_fr.pdf (que tu peux trouver ici : http://www1.bipm.org/fr/si/si_brochure/chapter2/2-1/second.html)
Indique que l'unité de base de temps du SI est la seconde (je te fais grasse de sa durée on s'en fout). La page 35 (page 39 du PDF) définie le jour ainsi :
Ce qui, et il le rappel, donne 1 j = 86 400 s. Le 30 juin a donc durée 1 j et 1 s. Selon le SI un jour dure 86 400 s et pas 86 401.
Tu t'énerve parce qu'il n'a pas indiqué qu'il parlait de la définition SI et pas du jour solaire ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Précisions
Posté par Nitchevo (site web personnel) . Évalué à 2.
Merci!
C'est agréable de voir que l'on est compris et tu m'as épargné une réponse que je n'aurais sans doute pas su exprimer aussi clairement.
[^] # Re: Précisions
Posté par tetaclac . Évalué à 3.
Chuck Norris mesure très précisément un Chuck Norris !
[^] # Re: Précisions
Posté par hercule_savinien . Évalué à 6.
Mais non, arrête tes complexes.
Personne n'a dit que tu était vieux.
Le FN est un parti d'extrême droite
[^] # Re: Précisions
Posté par Zenitram (site web personnel) . Évalué à -2.
Mes cheveux qui se barrent me disent le contraire ;-).
Bref. J'ai perdu mes cheveux.
[^] # Re: Précisions
Posté par 2PetitsVerres . Évalué à 2.
Et sinon un jour de [insérez ici n'importe quelle planète autre que la terre] est vachement différent d'un jour de la Terre. (dans la plupart des cas)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Précisions
Posté par barmic . Évalué à 2.
D'après ce que j'ai compris il y a d'autres effets en plus, par exemple les marées et la fontes des glaces influeraient sur les mouvements de la lune. Si je ne me trompe pas elle s'écarte de la Terre ce qui doit aussi avoir un impact sur le temps qu'elle met à nous tourner autour.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Argl c'était donc ça.
Posté par Nanawel (site web personnel, Mastodon) . Évalué à 3.
Je me demandais aussi pourquoi subitement mes 2 services tournant sous Java sur mon home server se sont mis à exploser la charge CPU toute la journée d'hier après plus de 200 jours d'uptime sans heurt…
Bon, je préfère ça.
[^] # Re: Argl c'était donc ça.
Posté par Crao . Évalué à 3.
Moi c'est VirtualBox qui s'est mis à bouffer du CPU comme un fou. Encore Oracle ;)
[^] # Re: Argl c'était donc ça.
Posté par Nanawel (site web personnel, Mastodon) . Évalué à 9.
Oracle aurait-il donc du mal avec le Temps ?
C'est digne d'une tragédie grecque…
# Défaillant par conception
Posté par Deuterium . Évalué à 7.
L'ajout d'une seconde intercalaire modifie le timestamp unix, et non pas seulement la représentation textuelle humaine de l'heure. Sur vos systèmes, il y a donc bien eu une seconde (informatique) qui a duré deux secondes (physiques), et ce mondialement. Le timestamp est tout sauf le nombre de secondes écoulées depuis epoch.
La solution serait de conserver le temps atomique dans le timestamp, et de faire gérer les secondes intercalaires par zoneinfo et compagnie (C'est d'ailleurs ce que certains ont fait, mais attention : si ils installent ou activent NTP un jour, ils se retrouveront avec 2 secondes de décalage au lieu d'une seule)
Les applications bien conçues qui veulent une représentation linéaire du temps (Apache, MySQL..) travailleraient en timestamp, avec conversion UTC à l'affichage seulement. Celles qui travaillent dans le futur avec du temps humain (ce crédit doit être remboursé le 1er Mai 2030 à 00:00 heure de Paris) stockeraient tout en UTC.
[^] # Re: Défaillant par conception
Posté par Antoine . Évalué à 3.
Apparemment, avec la glibc (?), ça dépend de la timezone :
[^] # Re: Défaillant par conception
Posté par Deuterium . Évalué à 1.
Ah merde j'ai une chance sur deux d'avoir dit une connerie alors (en même temps, ma seule source c'est wikipédia et une vieille ML ntp)
# En fait, on a besoin des deux échelles de temps...
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 7.
Malheureusement, Unix ne donne accès qu'à UTC (et pas à TAI ni à une autre échelle strictement monotone) donc des applications qui n'ont pas besoin de l'heure « civile » sont quand même forcées de l'utiliser :
http://www.bortzmeyer.org/leap-second-or-not-leap-second.html
[^] # Re: En fait, on a besoin des deux échelles de temps...
Posté par calandoa . Évalué à 8.
Je te trouve un peu défaitiste lorsque tu dis qu'on ne pas patcher la Terre. On pourrait imaginer, lorsqu'on s'aperçoit que le décalage entre UTC et UT1 devient trop grand, d'inverser le courant dans toutes les éoliennes du monde en les alimentant avec du nucléaire, et de les faire tourner à pleine puissance pendant 6 mois pour corriger la rotation de la Terre. Ça éviterai la consommation d'énergie intempestive des CPU comme sur le serveur de linuxfr.
Enfin bon, je sens qu'il va encore y avoir des rabats-joie pour prétendre que ça ne peut pas se faire aussi facilement.
[^] # Re: En fait, on a besoin des deux échelles de temps...
Posté par Octabrain . Évalué à 4.
On avait déjà une éolienne très puissante, mais on a dû l'arrêter le 15 mai 2012. Et depuis qu'on l'a arrêtée tout fout le camp, il faut des leap seconds…
[^] # Re: En fait, on a besoin des deux échelles de temps...
Posté par CHP . Évalué à 3.
Perso j'avais pensé à ce que tous les humains se mettent à courrir dans le meme sens pendant un certain temps ^
[^] # Re: En fait, on a besoin des deux échelles de temps...
Posté par 2PetitsVerres . Évalué à 2.
genre tout le monde fait un tour dans le même sens. Ça changera la vitesse angulaire (du reste) de la Terre pendant qu'on bouge. Il faudra peut-être plusieurs tours pour arriver à une seconde de décalage, cela dit.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: En fait, on a besoin des deux échelles de temps...
Posté par gnuzer (site web personnel) . Évalué à 2.
Ça me fait penser à https://xkcd.com/162/
# Merci
Posté par CrEv (site web personnel) . Évalué à 2.
Pour l'info, j'ai pu voir qu'un de mes serveurs perso était touché par un mysql qui prenait un core entier.
Personnellement j'aime bien ce genre de petite histoire. Si je ne me trompe pas d'ailleurs, la seconde intercalaire, même si ça ne s'est pas encore produit, peut être négative.
[^] # Re: Merci
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 1.
Oui, elle peut être négative mais c'est peu probable : la Terre ne fait que ralentir, je ne vois pas bien quel phénomène physique la ferait accélerer d'une seconde…
[^] # Re: Merci
Posté par claudex . Évalué à 7.
Une épidémie de rhum peut-être.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Merci
Posté par 2PetitsVerres . Évalué à 4.
On appelle ça une beuverie, non ? /o\
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Merci
Posté par feth . Évalué à 2.
J'imagine qu'un changement de sa forme doit agir ainsi : si le diamètre à l'équateur se réduit suite à un séisme par exemple, on aura le même phénomène que lorsque, tournant à grande vitesse, bras tendus vers l'extérieur avec un poids dans chaque main sur nos fauteuils de bureau rotatifs, on rentre les bras : accélération de la rotation.
[^] # Re: Merci
Posté par Antoine . Évalué à 2.
On sent le vécu…
[^] # Re: Merci
Posté par feth . Évalué à 2.
J'ai en effet déjà vécu un séisme qui a accéléré la rotation de mon astre, mais je pense qu'il en va de même pour la plupart des commentateurs ici.
[^] # Re: Merci
Posté par CHP . Évalué à 2.
C'est un phénomène que j'avais observé étant petit quand je faisais de la balancoire, et que j'ai mis longtemps à comprendre
[^] # Re: Merci
Posté par windu.2b . Évalué à 3. Dernière modification le 03 juillet 2012 à 07:33.
Une météorite qui la percute par derrière (par rapport à sa trajectoire autour du soleil) ?
[^] # Re: Merci
Posté par Alex G. . Évalué à 4.
Pas sûr que la seconde intercalaire soit notre souci majeur à ce moment là :-)
[^] # Re: Merci
Posté par Alex G. . Évalué à 2.
Oui merci aussi, je me demandais pourquoi mon solr tournait à fond les ballons !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.