News Schaltsekunde legte weltweit Server lahm

[Roy Batty]

Hmm... Wenn der Linux-Kernel in dem Ausmaße (also von 2.6.x bis 3.3) betroffen ist, wundert es mich, dass die Millionen und aber Millionen an Androids nicht abgeschmiert sind ^^. Verwenden ja auch den Linux-Kernel (natürlich in abgewandelter Form).

Wenn Android einmal mehr am Tag abstürzt, fällt das doch nicht weiter auf...

 

[castol]

hätte man da nicht einfach die Serverzeit um eine Sekunde nach vorne verändern können?
Aber wirklich interessant was ein Hype gemacht wurde, damit man das Jahr 2000 mit seinem PC miterlebt und dann haut eine Sekunde mehrere Systeme weg...

 

[balanceKeeper]

Wenn eine Schaltsekunde eingefügt wird, wird ein Logeintrag angelegt. Da im Log natürlich auch die Uhrzeit vorhanden sein soll, muss der Loghandler (klogd) die Uhrzeit holen. Der Zugriff auf die Zeit ist aber während des Timer-Interrupts gesperrt, also wartet der Interrupt auf den Loghandler und der Loghandler auf den Interrupt. Dadurch gibts dann einen schönen Deadlock.

Quelle: https://lkml.org/lkml/2009/1/2/373

Danke für den Link, aber die Erklärung ist nicht ganz korrekt.
Es ist schon richtig, dass der Kernel aus dem Timer Interrupt den klogd aufweckt, um in die Logs zu schreiben, dass eine Schaltsekunde eingefügt wurde, aber er hängt sich nicht auf, weil er die Zeit für die Logs braucht, sondern weil der Scheduler, der den Prozessen die CPU-Zeit gibt, eben auf die Zeit zugreift (um z.B. zu erfahren, wann die Scheduler-Ticks getriggert werden müssen). Der Scheduler wird hier angestossen, weil klogd aufgeweckt wird. (Aufwecken heißt: Task auf TASK_RUNNING umstellen, Rescheduling-Flag setzen und Scheduler aufrufen) Da die Zeit beim Umstellen gelockt ist, wartet der Scheduler, bis der Lock aufgelöst wird, was ja nie passiert, da der Timer-Interrupt wartet, bis der Scheduler seine Arbeit vollendet hat und klogd aufgeweckt wurde, um danach den Lock auflösen zu können => Deadlock.

Dieses Szenario folgt aus dieser Mail, es muss aber nicht heißen, dass es sich hier genauso abgespielt hat. Ich hab ebenso nicht die Sources analysiert, sondern nur den Inhalt der Mail gedeutet.

edit: Aus dem Mailverlauf lässt sich erkennen, dass es sich hier um den Fall handelt, wenn die leap-Sekunde dazugerechnet wurde. Beim Abziehen der Sekunde kann es ähnlich gewesen sein. Der vorgeschlagene Fix ist recht einfach, man logt, nachdem man den Lock aufgelöst hat, was bei den Kerneln von Red Hat und anderen LTS-Anbietern nicht so einfach gelöst werden könnte, da diese an anderen Stellen Locks setzen.

Ich konnte auch zwischen den Zeilen lesen, dass dieser Deadlock nur deshalb nicht immer stattfindet, weil der Scheduler nicht immer die Zeit auszulesen versucht.

edit2: btw. der 3.4 Kernel sieht nun aber ganz anders aus: http://lxr.free-electrons.com/source/kernel/time/ntp.c#L411
D.h. dies ist wahrscheinlich nicht die Ursache. (siehe Link aus dem Artikel: http://thread.gmane.org/gmane.linux.kernel/1321255/)

 

[McGybrush]

Man fliegt zum Mond, baut Atomwaffen, klont Zellen, heilt Erbkrankheiten… Aber ne Uhr zu Programmieren scheint nen Grosses Problem zu sein.

2000 sollte die Welt untergehen, Apple schafft es bei der Sommer/Winterzeit nicht das der Wecker 1 Woche danach morgens Klingelt, und jetzt legt ne sekunde ganze Server lam. Dabei fällt mir auf, je kleiner die Zeit um so grösser das Problem. Google sieht das schon mit dem richtigen Auge

 

[Autokiller677]

hätte man da nicht einfach die Serverzeit um eine Sekunde nach vorne verändern können?
Aber wirklich interessant was ein Hype gemacht wurde, damit man das Jahr 2000 mit seinem PC miterlebt und dann haut eine Sekunde mehrere Systeme weg...

Ne nicht nach vorne, es sollte ja eine Sekunde dazukommen. Genau genommen wurde die Sekunde 23:59:60 einmalig eingefügt.

Wenn man vorstellt, verliert man Zeit, und zurückstellen kann man nicht einfach, weil man dann einen Zeitwert doppelt hat. Das wirft eine Maschine erst recht durcheinander.

Das einzige, was ich mir noch vorstellen könnte, wäre die Uhr einfach eine Sekunde anzuhalten. Aber das gibt bestimmt auch irgendwie Probleme.

 

[castol]

OK, aber die hochrangigen und bestens ausgebildeten programmiere kriegen so etwas nicht in den griff...
Naja, bei mir läuft noch alles mir egal

 

[Wums]

also wenn schon seit 40 Jahren ab und zu eine Sekunde hinzugefügt wird hätte man das schon irgendwann mal in die Software reinschreiben können, is ja nicht so als wär das jetzt was vollkommen neues gewesen. Das Schaltjahr funktioniert doch auch...

 

[dMopp]

Ergebnis:

NTP Daemon verursacht (sehr) hohe CPU-Last.

Lösung:

NTP anhalten, Datum (neu) setzten (quasy eine Sekunde anhalten, richtig, führt aber bei Zeitkritischen Anwendungen wie Transaktionen zu akuten Problemen...), NTP Dienst starten.


So zumindest der Großteil (wie auch beim WDR)


(macht im übrigen RIESIG Spaß das bei ner Serverfarm von HAND zu machen >_< (Mehrere Datacenter)

 

[Eisenfaust]

Linux ist und bleibt ein Frickelsystem. Mit unseren BSD Systemen ist nichts passiert, alle PostgreSQL Datenbanken haben weitergemacht wie bisher. Die Zeitsynchronisation via ntp verlief problemlos, auch für das ansonsten so zeitempfindliche Kerberos V/Heimdal.

Das kommt davon, wenn Fachinformatiker plötzlich Systementwickler spielen können ;-)

Ergänzung (3. Juli 2012)

OK, aber die hochrangigen und bestens ausgebildeten programmiere kriegen so etwas nicht in den griff...
Naja, bei mir läuft noch alles mir egal

im Linuxumfeld hochrangig, bestens ausgebildet? haha ... Komm mal zu uns und schau Dir unseren "Entwickler" an ... pfffffft

 

[dMopp]

@Eisenfaust:

Ey ja. Für die Businessentscheidungen ist allein das Productmanagement verantwortlich (Bin gelernter Entwickler aber aus weitaus mehr Spaß an der Arbeit nun Systemengineer :O )

 

[Xargan]

...
Schaltsekunden sind doch Jahrhunderte vorher bekannt, ebenso Schaltjahre und die zweijährliche Sommer-/Winterzeitumstellungen - bei letzterem gab es irgendwie noch nie Probleme.

Schaltsekunden sind leider nicht vorhersehbar, da dieses u.a. von der Erdrotation abhängig ist und diese sich in Zukunft sowohl in die eine als auch in die anderen Richtung entwickeln kann . Die normalen Schaltjahre sind natürlich bekannt, soweit uns kein größeres kosmisches Ereignis in die Quere kommt ...

 

[andr_gin]

Ne nicht nach vorne, es sollte ja eine Sekunde dazukommen. Genau genommen wurde die Sekunde 23:59:60 einmalig eingefügt.

1.) Der PC speichert Zeitangaben nie in Stunden, Minuten, Sekunden, sondern immer als Anzahl der vergangenen Zeiteinheiten seit einem bestimmten Datum. Üblich sind z.B. Millisekunden seit 1970 (32Bit) bzw. 1/10 Mio. Sekunden seit dem Jahr 0 (64Bit).

Bei dem von dir genannten Datum handelt es sich also um 0:00:00 des nächsten Tages und dort wird dann noch eine Sekunde eingeschoben.

2.) Ich frage mich ernsthaft, wer überhaupt auf die dämliche Idee gekommen ist, Schaltsekunden in den Kernel zu implementieren und nicht zu testen. Ich könnte mich jetzt wieder über die Linuxgemeinde auslassen bezüglich verspielte Freaks, aber ich glaube das lasse ich lieber.
Auf 99,999% der Server kann die Schaltsekunde komplett ignoriert werden, da die Uhrzeit sowieso von einer normalen Uhr kommt, die sowieso etwas falsch geht. Wer es wirklich so genau braucht, kann das ja mit der nächsten Synchronisation mit dem Zeitserver abgleichen.

Diese Schaltsekunde ist nur relevant, wenn als Basis für die Systemzeit wirklich eine Atomuhr genommen wird. Das ist gerade bei einer hand voll wissenschaftlicher Anwendungen so, die wirklich prezise Messungen benötigen und diese sind sowieso nicht an die Systemzeit gebunden.

3.) Einer Software, die auch nur halbwegs vernünftig programmiert ist, darf so etwas nichts machen. Hier muss man nur ein paar Grundsätze beachten:
.) Es ist nicht gesagt, dass ein Ereignis, das später eintritt auch eine spätere Uhrzeit hat. Diese kann zurückgestellt werden (z.B. bei Sommer/Winterzeit, oder händischer Korrektur der Uhrzeit)
.) Wenn man eine Zeitdauer ermitteln und weiterverarbeiten will, dann muss man einen Timer laufen lassen. Start und Ende abzugreifen ist nur als grobe Richtlinie zu verstehen. Das taugt für die Geschwindigkeit bei einem Fortschrittsbalken, aber mehr schon nicht.
.) Wenn man zwei Datumswerte vergleicht, dann immer auf gleich oder nicht gleich, aber keinesfalls auf neuer bzw. älter, wenn es um wichtige Entscheidungen geht (z.B. Änderungsdatum einer Datei für die Versionierung verwenden)
.) Die Uhrzeit des Erstellungsdatums sagt nichts über die Reihenfolge der Erstellung aus. Wenn man etwas danach sortieren will, dann muss man aufzählende Nummern vergeben. Das Systemdatum hier hierfür ungeeignet.

4.) Wenn man Code für die Uhrzeitbehandlung schreibt, dann muss man verdammt vorsichtig sein, da der Fehler nie auftritt und dann plötzlich auf allen Systemen. Das hat schon MS mit ihrem mp3 Player herausfinden müssen, der dann im ersten Schaltjahr nicht mehr gebootet ist.
Da macht man keine unnötigen Spielereien, die keiner unbedingt braucht bzw. muss den Code entsprechend absichern (z.B. Schleifenbegrenzer, die nach einer gewissen Anzahl an Durchläufen abbrechen, um Endlosschleifen zu vermeiden etc.) Man muss den Code auch so einfach halten, wie möglich, damit auch ohne Test die Funktionalität nachgewiesen werden kann.

 

[praktikantIT]

Danke für die Info.

@others
Wenn es einfach nur um "Ups, ich bin in der Vergangenheit" ginge, wäre das bei jedem Schaltjahr ein Problem....

 

[Darkwonder]

Jetzt weiß ich auch warum ich verschlafen habe die Sekunde war schuld. So etwas sollte man doch wie den Weltuntergang ankündigen.

Was solche Umstellungen für Probleme bergen können, warum sammelt man über 60 Jahre nicht einfach 60 Sekunden an und schaltet eine Minute drauf? Die Zeit passt dank Sommer und Winter Zeit eh nie wirklich und somit ist es eigentlich scheiß egal.

 

[andr_gin]

Danke für die Info.

@others
Wenn es einfach nur um "Ups, ich bin in der Vergangenheit" ginge, wäre das bei jedem Schaltjahr ein Problem....

Bei einem Schaltjahr wird gar nichts umgestellt. Es werden nur z.B. die Millisekunden seit 1970 gespeichert. Dank den Schaltjahren wird die Formel zur Umrechnung in Tag/Monat/Jahr einfach etwas komplizierter.

Mit was man den Fall am Ehesten vergleichen könnte, wäre die Sommer/Winterzeit. Hier wird zumindest bei Windows tatsächlich um 1 Stunde nach vorne bzw. zurück gestellt. Man kann z.B. die Urheit manuell beim Wechsel von Winterzeit auf Sommerzeit auf 2:30 stellen, was an diesem Tag keine gültige Uhrzeit ist.

Was solche Umstellungen für Probleme bergen können, warum sammelt man über 60 Jahre nicht einfach 60 Sekunden an und schaltet eine Minute drauf? Die Zeit passt dank Sommer und Winter Zeit eh nie wirklich und somit ist es eigentlich scheiß egal.

1.) Es ist nicht genau einmal im Jahr und ist nicht konstant. Der Mond bremst durch die Gezeiten die Umdrehung der Erde, wodurch ein Tag immer länger wird => wir brauchen immer mehr Schaltsekunden in immer kürzeren Abständen.

2.) 1 Sekunde stört selbst die Leute nicht, die eine genaue Uhrzeit brauchen (z.B. Zeiteinblendungen im Fernsehen). Das ist bei allen Uhren übliche Toleranz.
1 Minute mehr oder weniger fällt auf. Das ist zwar nicht genug, damit es den Tagesablauf gravierend stört, jedoch gibt es schon mehr als genug Anwendungen, wo es zumindest auffällt z.B. Abfahrtstermine im öffentlichen Verkehr, Werbeeinschaltungen im Fernsehen etc.

 

[Tronx]

hat zwar erst mal wenig mit dem Problem hier zu tun aber viele hier können sich nicht mal vorstellen wenn es 0,0000 hinter dem Komma nicht "richtig" läuft, da versagen dann auch mal unsere Systeme und ich rede hier von Problemen wo mal eben ganze System aus dem "Takt" kommen, wenn das passiert ist erst einmal Feierabend (kann und darf leider nicht mehr ins Detail gehen) ;-)
wir setzen übrigens auf mehrfache Absicherung - GPS, AtomUhr und interne Taktkontrolle (einfach ausgedrückt).

 

[LundM]

aus dem grund googles idee 1 stunde

man kann die idee aber weiter spinnen und einen automatischen anpassmodus coden den man manuel startet entwickeln.

die uhr kennt also dann auch eine 25 stunde am tag

wen der wecksel heut statfinden soll startet man den code und die uhr wird dann 23:59 24:00 zählen.

danach kann man negativ und positiv ziten einstellen ohne system crash!

leider müssten dann alle in der zeitzone ligenden server für 10 secunden ca ihren dienst einstellen.

besser als teilweiße stunden ausfäle mit 12-14 stunden folge problemen.

positiv wäre dann: 23:59:59, 24:00:00 und beim nächsten sprung sofort auf 24:00:02
die stunden umstellung auf 0:00:03 oder 0:00:04 reingetimet und das system crasht nicht.

2 step verfahren ohne den standartisierten algorithmus zu stören.

edit: achso wer jetzt denkt warum nicht 23:59:59 24:00:00 0:00:00 damit würden wir uns wider steinzeitlich verhalten es wäre nur eine uns bekannte zeitjustierung möglich.

es wäre aber auch möglicch das wir bald 2 secunden anpassen müssen oder nach einem ereignis sei es natural oder menschlich negativ anpassen müssten.

 

[am3000]

wir sind alle 1 Sec Älter geworden
kein wunder dass das einen Crash gab das hätten die lieber um 1 Uhr machen sollen und nicht um 23.59 wo grade auf das neue Datum umspringt

 

[Klingerdennis]

von wegen linux stürzt nicht so schell ab wien windows
warum habense eg nicht die schaltsekunde übersprungen? wofür idt die derartig geneue zeit nötig?

 

[Facepalm]

Wir sind so fortschrittlich...
Können zum Mond fliegen und haben PC`s im Hosentaschenformat, aber Software so zu
entwickeln, das das einfügen einer Schaltsekunde gleich zum Ausfall führt geht nicht ?

Linux hatte Probleme ?. Hoffentlich macht man jetzt nicht die NVIDIA Treiber dafür verantwortlich. F_CK Linux / Ironie aus. Gruss an Linus Torvalds