Schaltsekunde – alter Hut und Dauerbrenner

Zeit- und Datumsprobleme sind Dauerbrenner in der modernen IT. Wer erinnert sich nicht an das Jahr-2000-Problem? Unser Zeitsystem ist leider nicht linear und auf Schaltjahre, Schalttage, Schaltsekunden angewiesen. Dazu muss sich die IT mit Zeitzonen, Taktgebern, Datumsgrenzen in Datentypen verschiedener Programmiersprachen usw. auseinandersetzen. Da sind Probleme im wahrsten Sinne des Wortes  vorprogrammiert und keineswegs außergewöhnlich. Auch das Schaltsekunden-Problem taucht im Linux-Umfeld immer mal wieder auf, zuletzt 2008 und 2005. Am Wochenende war es mal wieder soweit, dass die Physikalisch-Technischen Bundesanstalt allen NTP-getriggerten Geräten eine Schaltsekunde verordnete. Obwohl etwaige Softwareprobleme im Zusammenhang mit dem Linux-Kernel spätestens seit März bekannt, diskutiert und auch im offiziellen Kernel behoben sind, machte Mozilla anlässlich der von Samstag auf Sonntag eingefügten Schaltsekunde gestern mit einer Meldung zum Thema von sich reden, die ich zum Anlass nehmen möchte, das Problem für all Jene noch einmal auszubreiten, die bisher über keine Schaltsekunde gestolpert sind.

So ließ Mozilla gestern in einem Blog-Eintrag verlauten, die eigenen Server hätten vom Zeitpunkt der Schaltsekunde an mit seltsamen Lastspitzen reagiert, die sich allerdings durch einen Neustart der Server,  bzw. das Neusetzen des Datums beseitigen ließen. Sollte Dich Dein Linux am Wochenende mit ähnlich merkwürdigen Phänomenen geärgert haben – was allerdings bei einem aktuelle Standard-Kernel unwahrscheinlich ist – interessieren Dich vielleicht die Hintergründe? Tun sie nicht? Egal, ich fühle mich trotzdem genötigt, hier die technischen Zusammenhänge auszubreiten. Ist Mal ein ganz anderes Problem, als das Secure-Boot-Problem, OpenSUSEs Termin-Problem oder das Problem, welches Oracle und Google miteinander haben und ganz nebenbei auch technisch interessant.

Hast Du’s gemerkt?

Und zwar hatte die Physikalisch-Technischen Bundesanstalt (PTB), bzw. der „International Earth Rotation and Reference Systems Service“ (IERS) für die Nacht vom Samstag, dem 30.06.12 auf Sonntag, dem 01.07.12 allen NTP-gesteuerten Computern und Controllern eine sogenannte “positive Schaltsekunde”  von 23:59:59 UTC auf 23:59:60 UTC verordnet. Die Umstellung in Deutschland erfolgte um 2 Uhr morgens, weil unsere Mitteleuropäische Sommerzeit bekanntlich auf der UTC (koordinierte Weltzeit) basiert, allerdings um 2 Stunden verschoben (MESZ = UTC+2). Schaltsekunden sollen dem “Auseinanderdriften”  von  Uhrzeit und Tagesverlauf (Sonnenstand) entgegenwirken und dafür sorgen, dass die koordinierte Weltzeit (UTC) nie mehr als 0,9 Sekunden von der „universelle Sonnenzeit“ (UT1), auch „astronomische Zeit“ genannt, abweicht.

Physikalische Geschichtsstunde

Webseite PTB: Koordinierte Weltzeitskala

Klingt logisch oder? Doch was bedeutet das? Dazu will ich etwas ausholen. Noch bis in die 50’er Jahre des letzten Jahrhunderts (klingt lange her, aber wir reden hier von 1950) war eine „Sekunde“ als der 86400’ter Teil eines „mittleren Sonnentages“ definiert. Da aber eine vom Sonnenstand und damit der Erdrotation abgeleitete Zeitskala nie streng gleichförmig verläuft, weil die Erdumdrehungsgeschwindigkeit unregelmäßigen Schwankungen unterliegt, was langfristig eine Verlangsamung bewirkt, ist eine solche Zeitskala für wissenschaftliche und technische Zwecke unbrauchbar. Die Sekunde ist daher seit 1967 über die Schwingungsdauer des Cäsiumatoms unter der Bezeichnung „Internationale Atomzeit“ (TAI) definiert. Demnach ist eine Sekunde das 9192631770-fache der Periode einer Schwingung des Caesium-Atoms. Für unseren Alltag ist aber die UTC (koordinierte Weltzeit), nebst der daraus abgeleiteten Zeittonen, maßgeblich, die sich an der TAI orientiert, allerdings aufgrund der geschilderten astronomischen Zusammenhänge von Zeit zu Zeit mit der ungleichförmig verlaufenden „Universal Time“ UT1 synchronisiert werden muss, die z. B. immer noch für astronomische Zwecke benötigt wird. Aktuell liegen UT1und TAI 35 Sekunden auseinander. Der „Internationalen Dienst für Erdrotation und Referenzsysteme“ (IERS)  führte die Schaltsekunde erstmals im Jahr 1972 ein, in dem die Abweichung zwischen UT1 und TAI bereits 10 Sekunden betrug. Die letzten Schaltsekunden der näheren Vergangenheit gab es 2005 und 2008.

Man muss sich zu helfen wissen

Scheinbar betrifft das Schaltsekunden-Problem auch die aktuelle Debian-Version Squeeze, denn laut einem Blog-Eintrag auf „serverfault.com“ hätten zahlreiche Rechner eines Datacenters nach Einfügen der Schaltsekunde nicht mehr auf Pings reagiert, was die zuständigen Admins durch Stoppen des NTP-Daemons und Zurücksetzen des Schaltsekunden-Bits im Kernel in den Griff bekamen und bestätigt, das das Verhalten im Linux-Kernel begründet liegt, weil die durch das NTP-Subsystem eingefügte Schaltsekunde eine Deadlock-Situation verursacht. Betroffen sind alle Kernel-Versionen von 2.6.26 bis einschließlich 3.3, was allerdings seit Längerem bekannt ist.

Erwähnenswert ist meines Erachtens noch, wie Google ungeachtet der Verwendung gepachter Kernel, auf das Problem reagiert, nämlich mit einer Lösung die keine ist, aber funktioniert und zwar durch „Vorbeugen“. Google setzt dazu in den  eigenen Serverparks auf selbst erdachtes Verfahren unter der Bezeichnung „leap smear“. Dabei sorgt Google mit modifizierten NTP-Servern dafür, dass an dem Tag der Schaltsekunde mit jedem NTP-Update einige Millisekunden eingefügt werden, die sich bis zum nächsten Schaltzeitpunkt zu einer Sekunde addieren.

Das Ende der Welt

Wenn man bedenkt, dass das seinerzeit unübersehbare Year2k-Problem damals  das Potenzial für Weltuntergangsszenarien hatte (“unter” Totales Chaos ging gar nichts) , was damals zahlreichen Cobol- und Assembler-Experten das Aufheben ihres Altersruhestandes mit satten Sondereinnahmen bescherte, nehmen sich Schaltsekundenprobleme geradezu mickrig aus. Da stimmen mich Entwicklungen wie Stuxnet oder Flame schon eher nachdenklich, wenn man bedenkt, wo in unserer modernen Industriegesellschaft überall SCADA-Systeme von Siemens oder sonstige SBS-Lösungen werkeln. Ader das Alles dürftige sich mit dem Ende des Maya-Kalender in Kürze eh relativieren. Im Übrigen überlegt die IERS, ob das häufige Einfügen von Schaltsekunden aufgrund der erwartbaren technischen Probleme mit Computersystemen nicht lieber zugunsten einer ganzen Schaltstunde im Jahr 2600 ausgesetzt werden sollte. Immerhin dürften bis dahin etwaige Fehlerquellen in Ubuntu 600.04, Fedora 523 und Debian 8 ausgemerzt sein. Die Entscheidung darüber wurde allerdings auf das Jahr 2015 vertagt, wahrscheinlich um erstmal abzuwarten, was aus dem Maya-Kalender wird.