13. Mai 2006, kurz nach Mitternacht UTC.
Einige Webserver rund um den Globus beginnen plötzlich zu stolpern. Prozesse frieren ein, geplante Tasks bleiben hängen, manche Maschinen wirken, als seien sie in einer Zeitschleife gefangen. Kein Angriff, kein Stromausfall – sondern etwas viel Grundsätzlicheres: Die Zeit selbst gerät aus dem Takt.
Für die meisten Administratoren war es ein Rätsel.
Für AOLserver, den damals weitverbreiteten Open-Source-Webserver, markierte dieser Moment das Ende von „Nie“ – oder, poetischer gesagt: das Ende der Ewigkeit.
Aus einem unscheinbaren Timeout-Wert wurde an diesem Tag ein Stück Computergeschichte:
die Geburtsstunde des Y2K38-Bugs.
The Edge of Time – Das Ende der Ewigkeit
Die Zeit, wie Computer sie verstehen, ist keine mystische Größe. Sie beginnt an einem klar definierten Punkt: dem 1. Januar 1970, 00:00:00 UTC.
Seit diesem Moment zählt ein einfacher Zahlenwert jede vergangene Sekunde – die sogenannte Unixzeit. Sie ist das Fundament nahezu aller modernen Betriebssysteme: von Linux und macOS bis zu Android und zahllosen eingebetteten Geräten.
Doch dieser scheinbar endlose Zähler hat eine Grenze. In klassischen 32-Bit-Systemen kann die Unixzeit nur bis 2 147 483 647 Sekunden reichen. Danach „läuft sie über“.
Dieser Moment wird am 19. Januar 2038 um 03:14:07 UTC eintreten – der Zeitpunkt, an dem alle Programme, die mit einer signierten 32-Bit-Zeit arbeiten, plötzlich in die Vergangenheit springen: in das Jahr 1901.
Wir von der BEOZ Association bezeichnen diesen Moment als „The Edge of Time“ – die rechnerische Kante der digitalen Gegenwart. Andere sprechen von der „Epochalypse“, in Anlehnung an die „Unix Epoch“, also den Beginn dieser Zeitrechnung.
Was nach Science-Fiction klingt, ist ein sehr reales technisches Problem:
Zahlreiche Systeme – von älteren Datenbanken über IoT-Geräte bis hin zu industriellen Steuerungen – speichern Zeitwerte noch immer in diesem 32-Bit-Format. Wenn sich die interne Uhr einem Wert nähert, den sie nicht mehr darstellen kann, entstehen Überläufe: Berechnungen liefern negative Ergebnisse, Timer laufen sofort ab, Protokolle springen in die Vergangenheit.
Das Jahr 2038 markiert somit keine symbolische Grenze, sondern eine technische Singularität, an der sich zeigt, wie eng Mathematik und Realität in der Informatik verknüpft sind.
Und während für viele Systeme diese Grenze noch bevorsteht, traf sie eines schon früher – im Mai 2006, als der Webserver AOLserver mit einer „unendlichen“ Zahl über die Kante der Zeit hinausrechnete.
Wenn ‚Nie‘ zu Ende geht – AOLserver-Timeout deckt Jahr 2038 Problem auf
Im Frühjahr 2006 traten bei mehreren Installationen des Open-Source-Webservers AOLserver unerklärliche Ausfälle auf. Geplante Aufgaben liefen nicht mehr, Datenbankverbindungen blieben hängen, einzelne Prozesse froren scheinbar ohne Grund ein. Die Systeme waren stabil, die Netzwerke gesund – und doch geriet der Server ins Straucheln.
Die Spur führte zu einer unauffälligen Stelle in der Konfiguration:
MaxOpen = 1000000000
MaxIdle = 1000000000
Diese Werte, in Sekunden angegeben, sollten sicherstellen, dass Verbindungen zu Datenbanken niemals automatisch geschlossen werden. „Eine Milliarde Sekunden“ – etwa 31,7 Jahre – erschien lang genug, um als „ewig“ zu gelten. Doch diese scheinbar harmlose Zahl brachte den Server aus dem Gleichgewicht.
Am 13. Mai 2006 erreichte die aktuelle Zeit den Punkt, an dem „jetzt + 1 000 000 000 Sekunden“ erstmals über die 32-Bit-Zeitgrenze von 2 147 483 647 Sekunden hinausführte. Aus einem zukünftigen Zeitpunkt wurde – rechnerisch – ein Datum in der Vergangenheit. AOLserver interpretierte die betroffenen Zeitstempel als längst abgelaufen: Verbindungen wurden sofort beendet, Timer sprangen auf null, Scheduler blockierten.
In der Entwickler-Mailingliste identifizierte Dossy Shiobara, der damalige Maintainer, die Ursache:
„For those who are curious, here’s the explanation as to what was going on back in May 2006 when AOLserver installations started mysteriously «hanging».
It turns out that the default MaxOpen and MaxIdle values in some OpenACS sample configuration files are set to 1000000000 (1 billion) seconds, which works out to about 31.7 years. When these values are added to the current system time (now), the resulting timeout value overflows the signed 32-bit integer that represents Unix time.
This causes the calculated timeout to be negative, so connections appear to have already expired, or the server simply hangs waiting for an impossible timeout in the past.
So, yes — this is basically a manifestation of the Year 2038 problem, it just happened early because of the configuration.»
„Für alle, die es interessiert, hier die Erklärung, was im Mai 2006 passierte, als AOLserver-Installationen plötzlich auf mysteriöse Weise „einfrieren“ begannen.
Es stellte sich heraus, dass in einigen Beispiel-Konfigurationsdateien von OpenACS die Standardwerte für MaxOpen und MaxIdle auf 1 000 000 000 Sekunden (eine Milliarde Sekunden) gesetzt sind, was etwa 31,7 Jahren entspricht.
Wenn diese Werte zur aktuellen Systemzeit (now) addiert werden, überläuft das Ergebnis den signierten 32-Bit-Integer, der die Unixzeit darstellt.Dadurch wird der berechnete Timeout-Wert negativ, sodass Verbindungen so erscheinen, als wären sie bereits abgelaufen – oder der Server hängt sich einfach auf, weil er auf einen unmöglichen Timeout in der Vergangenheit wartet.
Ja, das ist im Grunde eine Ausprägung des Jahr-2038-Problems – sie trat nur früher auf, weil sie durch die Konfiguration ausgelöst wurde.“
– Dossy Shiobara (2006)
Das Problem war also kein klassischer Programmierfehler, sondern ein Grenzfall der Zeitdarstellung.
Die Unixzeit, seit 1970 als fortlaufende Zahl von Sekunden gezählt, war für diese Berechnung schlicht zu klein. Was als praktische Abkürzung für „niemals“ gedacht war, wurde zur ungewollten Zeitbombe.
Shiobara empfahl, die Werte durch realistische Limits zu ersetzen – zum Beispiel 3600 Sekunden (eine Stunde) oder 0 für „deaktiviert“. Betroffen waren vor allem Konfigurationen, die auf Empfehlungen aus dem OpenACS-Projekt basierten. Auf Solaris-Systemen führte der Überlauf zu Fehlermeldungen (EINVAL bei pthread_cond_timedwait), während Linux-Systeme sich einfach „aufhängten“.
Der Vorfall machte erstmals deutlich, dass das Jahr-2038-Problem keine ferne Theorie war, sondern eine konkrete, messbare Schwachstelle in realen Anwendungen. Eine falsche Annahme über Zeit – und das Vertrauen, dass „ewig“ auch im Code ewig bleibt – reichten aus, um produktive Systeme lahmzulegen.
In einem späteren Blog-Post brachte es Dossy Shiobara, Maintainer des AOLservers, prägnant auf den Punkt:
«You could call this the first “Y2038” bug»
„Man könnte dies den ersten ‚Y2038‘-Fehler nennen“
– Dossy Shiobara (2006)
