News Schaltsekunde legte weltweit Server lahm

cartridge_case schrieb:
hat noch einer ne gute erklärung wieso genau es nun dazu kam?
Da schließe ich mit an. Eine Erklärung für einen Fehler kenne ich auch nicht. Server werden doch generell mit eigener Uhr laufen und sich ab und an mal per NTP eine neue Zeit zum Stellen holen. Und bei der neuen Zeit bei der NTP-Abfrage wird die Schaltsekunde einfach mit drin sein. Wo ist das Problem?
 
Also das Problem ist schon ein wenig komplexer als es in den News dargestellt wird.

Damit ein Server betroffen ist muss:

1. ein dafuer anfaelliger Kernel laufen (gibt sehr viele, 2.6.26 bis 3.3) - der Patch wurde allerdings schon im Maerz(!) gepostet: https://git.kernel.org/?p=linux/ker...it;h=6b43ae8a619d17c4935c3320d2ef9e92bdeed05d

2. Muss der NTP Daemon laufen. Wer z.b. nur einmal pro Tag die Zeit mit einem Zeitserver synct, war nicht betroffen. Der NTP Daemon laeuft immer, und trackt auf den Drift der internen Uhr mit dem Zeitserver ab, und die Systemzeit noch genauer halten zu koennen.

3. Muss dieser NTP Daemon unzureichend konfiguriert sein. Man kann naemlich eine leap-seconds.list aus dem Internet laden und diese dem NTP Daemon zur verfuegung stellen, dann weiss der genau wann eine Leap Second kommt und wie er darauf reagieren soll.

also alter bzw ungepatchter Kernel UND unzureichend konfigurierter Daemon -> Fazit? -> User bzw. Adminfehler
 
Telesto schrieb:
Und 2100 schmieren sämtliche Windows-Rechner ab, weil die Programmierer es immer noch nicht schaffen mehr als 10 Jahre voraus zu denken. Klingt aus heutiger Sicht nicht problematisch, aber bei Y2K-Problem dachte auch niemand, dass die in den 80ern entwickelte Software mehr als 20 Jahre im Einsatz sein würde. Bei der heutigen Verbreitung von Computern würde ich es daher auch nicht ausschließen, dass 2100 irgendwelche Geldautomaten in der dritten Welt oder Computer in Lichtjahren entfernten Sonden abstürzen, die noch auf Windows 7 laufen. Y2.1K dann quasi.

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

genau, ne weltraumsonde hat als betriebssystem windows 7.. und der servicepack wird hinterhergschossen, dockt an und installiert sich dann selbst an einer außen-usb-schnittstelle :stacheln:
 
also ich hab nicht einen server übers wochenende verloren ... meine systeme laufen mit 2.6 bzw. 3.2

glück gehabt ^^
 
@Ulukay: Ich kann mir einen Fehler nur vorstellen, wenn ein System die Uhrzeit per NTP abfragt und 23:59:60 angesagt bekommt. Das passiert bei einem NTP Daemon? Ich weiß nämlich nicht, was das ist. ;)
 
Weils nen Bug im Kernel gab, der vom falsch konfigurierten NTP Daemon getriggert wurde. So einfach ist das.
 
moko schrieb:
Am falschen Ende gespart! Mit Windows währe das nicht passirt! :freak:

-> wäre
-> passiert


soweit ich weiss ist das auch kein Softwareproblem, sondern ein Problem im Kernel an sich, betrifft also potentiell alle Unix Systeme :/
 
einfach nur traurig das unsere "welt" so aufs internet/pc/software getrimmt is und sowas lapides soviel "schaden" anrichten kann... unglaublich
 
Telesto schrieb:
Bei der heutigen Verbreitung von Computern würde ich es daher auch nicht ausschließen, dass 2100 irgendwelche Geldautomaten in der dritten Welt oder Computer in Lichtjahren entfernten Sonden abstürzen, die noch auf Windows 7 laufen. Y2.1K dann quasi.

Raumsonden mit Windows OS und Internetzugang:D
 
Asghan schrieb:
sondern ein Problem im Kernel an sich, betrifft also potentiell alle Unix Systeme :/

Aber Unix Systeme haben doch eigene Kernel. Wär mir neu dass richtige Unix Maschinen wie Solaris oder AIX den open source Linux Kernel einsetzen.
 
Asghan schrieb:
-> wäre
-> passiert


soweit ich weiss ist das auch kein Softwareproblem, sondern ein Problem im Kernel an sich, betrifft also potentiell alle Unix Systeme :/

Nein, denn Unix!=Linux!
Aber danke für die Korrekturen, denn dieselbe Idee hatte ich auch... :P
 
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
 
Ich könnte mir vorstellen, dass ein paar Server ausgefallen sind und die anderen dann die Last übernehmen mussten und dementsprechend langsamer waren.
 
webwebber schrieb:
genau, ne weltraumsonde hat als betriebssystem windows 7.. und der servicepack wird hinterhergschossen, dockt an und installiert sich dann selbst an einer außen-usb-schnittstelle :stacheln:

YMMD :evillol:
 
Vielleicht funktioniert ja jetzt der Wecker der iPhones wieder zuverlässig. Apple ist halt immer einen Schritt voraus :D
 
Zurück
Oben