Der 49-Tage-Bug in macOS 26 Tahoe: Was wirklich dran ist…

"Bug in macOS 26 Tahoe: Server stürzen nach 49 Tagen ab" oder "Apple MacBooks werden wegen macOS-Zeitbombe nach 49 Tagen langsamer" ... Die Schlagzeilen haben in den letzten Tagen langsam Bildzeitungsniveau erreicht, und ich dachte, es ist an der Zeit, das eigentliche Problem mal nüchtern zu betrachten. Wie so oft ist es nämlich so, dass die Medien die Sache ordentlich aufblasen, um Klicks zu bekommen.

Ich habe mir die Originalquelle und die Diskussionen auf TidBITS und Hacker News angeschaut und fasse euch mal zusammen, was wirklich passiert ist und wen es überhaupt betrifft. Bitte entschuldigt die Länge des Artikels, aber um es kürzer zu machen, hätte ich viele Sachen weglassen müssen, die ich aber eigentlich wichtig finde, um diesen Bug und die Meldungen dahinter zu verstehen.

Woher kommt die ganze Aufregung?

Ausgangspunkt ist ein Blogpost der Firma Photon. Das ist eine Firma, die Software entwickelt und die sich aktuell sicher über diel Publicity und die Backlinks freut. Aber ich gönne es den Leuten, weil sie vermutlich viel Zeit mit der Erforschung des Fehlers verbracht haben. Photon bietet eine Infrastruktur, mit der andere Dienste automatisiert iMessage-Nachrichten verschicken können. Damit das klappt, betreiben sie einen ganzen Schwung Macs, die im Dauerbetrieb laufen und praktisch nie ausgeschaltet werden.

Und genau dort sind ihnen die Macs regelmäßig mit kaputtem Netzwerk aufgefallen. Statt sie einfach neuzustarten und weiterzumachen, haben sie sich die Mühe gemacht, der Sache im Quellcode des macOS-Kernels auf den Grund zu gehen. Der Kernel ist sozusagen das Herzstück des Betriebssystems, und bei macOS heißt er "XNU". Apple veröffentlicht große Teile davon als Open Source, man kann also tatsächlich reinschauen, was da passiert.

Die Kernaussage von Photon klingt dramatisch: Nach exakt 49 Tagen, 17 Stunden, 2 Minuten und 47 Sekunden ununterbrochener Laufzeit friert in macOS 26 eine interne Uhr ein, mit der der Mac seine Netzwerkverbindungen verwaltet. Die Folge: Irgendwann lassen sich keine neuen Verbindungen ins Internet mehr aufbauen.

In der Praxis heißt das, dass Webseiten nicht mehr laden, Mails nicht mehr rein oder raus kommen, der App Store leer bleibt und iMessage-Nachrichten im Versand hängen. Verbindungen, die schon länger laufen, funktionieren zunächst weiter, aber jeder Versuch, eine neue aufzumachen, scheitert.

Kurioserweise funktioniert der sogenannte "Ping" ebenfalls weiter. Das ist ein einfacher Test, mit dem man prüfen kann, ob ein anderer Rechner im Netzwerk überhaupt erreichbar ist, und der läuft über ein anderes Protokoll. Das macht die Fehlersuche besonders tückisch, denn wer im Terminal zum Beispiel ping sir-apfelot.de eingibt, bekommt saubere Antwortzeiten zurück und denkt zunächst, das Netzwerk sei in Ordnung.

Der einzige Ausweg ist laut Photon ein Neustart. Und schon war die Schlagzeilenmaschine nicht mehr zu bremsen.

Tom's Hardware, Tom's Guide, TechRadar, iDrop News, Notebookcheck und The Mac Observer haben den Bug im Stundentakt durchgereicht und sich dabei gegenseitig in der Dramatik überboten.

Das Problem vom Nicht-Nerd für die Nicht-Nerds erklärt

Damit ihr versteht, was da im Hintergrund passiert, muss ich etwas ausholen. Ich bin selber kein Software-Entwickler, aber ich versuch es euch mal so zu übersetzen, wie ich es selbst verstanden habe.

Fast alles, was euer Mac im Internet macht, läuft über sogenannte TCP-Verbindungen. TCP ist eine Art Regelwerk dafür, wie zwei Rechner miteinander reden. Jedes Mal, wenn ihr eine Webseite aufruft, eine Mail abholt oder iMessage benutzt, baut euer Mac eine oder mehrere solcher Verbindungen zum jeweiligen Server auf. Danach werden Daten übertragen, und am Ende wird die Verbindung wieder geschlossen.

So weit, so unspektakulär. Interessant wird es beim Abbau einer solchen Verbindung.

Der reservierte "Parkplatz" namens TIME_WAIT

Wenn eine Verbindung geschlossen wird, gibt der Mac sie nicht sofort komplett frei, sondern er parkt sie für kurze Zeit in einem Zustand, der in der Fachsprache "TIME_WAIT" heißt. Auf macOS sind das 30 Sekunden. Stellt euch das wie einen reservierten Parkplatz vor, der noch eine halbe Minute lang blockiert bleibt, obwohl das Auto schon weg ist.

Warum dieser Aufwand? Im Internet können Datenpakete verzögert werden und verspätet ankommen. Wenn der Mac den Platz sofort wieder freigeben würde und direkt eine neue Verbindung mit denselben Eckdaten aufbaut, könnten verspätete Pakete der alten Verbindung plötzlich bei der neuen ankommen und alles durcheinanderbringen.

Die 30 Sekunden sind also ein Puffer, damit solche Nachzügler im Netz noch ankommen können, bevor der Platz neu vergeben wird. Von diesen Parkplätzen gibt es zwar viele tausend, aber eben nicht unendlich viele. Im Normalbetrieb ist das kein Problem, weil die Plätze ja nach 30 Sekunden wieder frei werden und der Mac neue Verbindungen annehmen kann.

Und jetzt kommen die 49 Tage ins Spiel…

Damit der Mac entscheiden kann, ob die 30 Sekunden schon um sind, braucht er eine interne Uhr. Und genau diese Uhr ist der Auslöser für den ganzen Aufruhr.

Im macOS-Kernel ist sie als ein einfacher Zähler mit dem Namen "tcp_now" umgesetzt, der die Millisekunden seit dem letzten Start des Macs mitzählt. Der Haken liegt in der Art, wie dieser Zähler gespeichert wird. Programmierer müssen beim Anlegen solcher Werte festlegen, wie groß sie maximal werden dürfen, und hier wurde ein Format gewählt, das bis zum Wert 4.294.967.295 zählen kann.

Das sieht erstmal nach viel aus, aber wenn man es in Millisekunden umrechnet, landet man bei genau jenen berühmten 49 Tagen, 17 Stunden und ein paar Minuten. Sobald der Zähler diese Grenze erreicht, läuft er über und fängt wieder bei Null an. Man kann sich das wie einen Kilometerzähler im alten Auto vorstellen, der nach 999999 Kilometern wieder bei 000000 startet.

In macOS 26 ist der Code an dieser Stelle fehlerhaft, und nach dem Überlauf bleibt die Uhr einfach stehen.

Jetzt spielen  "Uhr" und "Parkplatz" zusammen

Ihr ahnt vielleicht schon, worauf das hinausläuft. Wenn die Uhr steht, kann der Mac nicht mehr ausrechnen, ob die 30 Sekunden Parkzeit schon um sind. Er checkt die Uhr und die Uhr zeigt seit dem Überlauf immer die gleiche Zahl an. Das signalisiert dem Mac, dass die Zeit der Verbindungen nicht abgelaufen ist. Und in der Folge bleibt die Verbindung  für immer auf dem Parkplatz stehen.

Jeder neue Webseitenaufruf produziert eine weitere solche Verbindung, die nie abläuft, bis es irgendwann zu viele sind. Und dann ist Schluss mit neuen Verbindungen. In unserer Metapher wären dann alle "Parkplätze" belegt.

Übrigens: Das gleiche Prinzip mit überlaufenden Zählern ist in der Vergangenheit schon mehrfach aufgetreten. Windows 95 und 98 sind aus demselben Grund nach 49,7 Tagen abgestürzt, und das berüchtigte Jahr-2038-Problem unter Unix hat ebenfalls so einen Zähler als Wurzel. Solche Überläufe sind also keine Eigenart von macOS, sondern ein klassischer Programmierfehler, den es alle paar Jahre wieder gibt.

Schlagzeilen und Realität des "49 Tage Bugs"

Viele Medien haben die ganze Sache ziemlich dramatisiert. Wenn man allerdings die Diskussion auf Hacker News liest, bleibt von "jeder Mac ist betroffen" nicht mehr viel übrig. Eine kleine Zusammenfassung, was die Experten dort meinen:

Der Nutzer throw0101d hat dort zum Beispiel erzählt, dass sein Arbeits-MacBook unter macOS 15.7.4 (macOS Sequia) eine Uptime von 50 Tagen und 22 Minuten hatte, ohne irgendein TCP-Problem. Sein privater iMac lief sogar seit 279 Tagen ohne Neustart.

Ein anderer Nutzer namens comex hat dann die entscheidende Entdeckung gemacht. Er hat im öffentlich einsehbaren Quellcode von macOS nachgeschaut, wann genau die fehlerhaften Zeilen dort eingefügt wurden. Das geht, weil Apple wie schon erwähnt Teile des Kernels als Open Source veröffentlicht, und solche Codeänderungen werden auf der Plattform GitHub mit Datum und Zeitstempel dokumentiert. Sein Fund: Die problematischen Zeilen wurden erst in macOS 26 (Tahoe) eingebaut.

Das deckt sich übrigens mit der Beobachtung von John Gruber vom Apple-Blog Daring Fireball, der ebenfalls im Quellcode gesehen hat, dass die betreffenden Zeilen erst vor etwa sechs Monaten hinzugefügt wurden, während der Rest der Datei seit Jahren unverändert ist.

Auf Michael Tsais Blog wurde zwar kurz spekuliert, dass der Bug möglicherweise schon seit macOS Catalina existieren könnte, aber die Nutzerberichte aus den Kommentaren oben sprechen dagegen. Tahoe ist also tatsächlich der Übeltäter, und ältere Systeme sind sauber.

Wen betrifft der Bug realistisch?

Adam Engst hat auf TidBITS eine schöne nüchterne Einordnung dazu geschrieben, die ich hier mal so runterdampfen würde:

• Erstens werden die meisten normalen Macs ohnehin regelmäßig neugestartet, weil Apple laufend Sicherheitsupdates veröffentlicht und die nach der Installation einen Neustart verlangen. Wer also seine Updates brav einspielt (und das solltet ihr sowieso tun), wird den Bug nie zu Gesicht bekommen.
• Zweitens führt der Bug nicht zu einem sofortigen Ausfall nach 49 Tagen. Es werden einfach nur keine neuen Verbindungen mehr aufgebaut, und wie schnell das spürbar wird, hängt stark davon ab, wie intensiv der Mac genutzt wird. Auf einem Mac, der hauptsächlich Netflix streamt, kann es noch Tage dauern, bis ihr überhaupt etwas merkt.
• Drittens verlängert sich die Zeit deutlich, wenn der Mac zwischendurch schläft. Bei einem normalen MacBook, das abends zugeklappt wird, müsstet ihr wochenlang nonstop arbeiten, bis der Bug zuschlägt.
• Viertens, und das ist fast der wichtigste Punkt: Bei normalen Mac-Programmen wie Browsern, Mail oder dem App Store dauert es lange, bis der Bug überhaupt spürbar wird. Das liegt daran, dass diese Programme meistens nur kurze Verbindungen aufbauen, die vom Server geschlossen werden und nicht vom Mac selbst. Und der Parkplatz-Mechanismus mit TIME_WAIT greift eben nur dann, wenn euer Mac die Verbindung aktiv beendet hat.

Also, selbst wenn die 49 Tage abgelaufen sind und euer Mac in der Zeit nicht im Standby war oder neu gestartet wurde, können Wochen vergehen, bis sich soviele neue Verbindungen ansammeln, dass es für den Mac "zuviele" werden (der Grenzwert scheinen 16.000 zu sein). Wenn man einen Mac als Server betreibt und der ordentlich beschäftigt ist, kann die Menge allerdings schon nach wenigen Minuten voll sein.

Richtig auffallen dürfte der Bug also nur bei Anwendungen, die im großen Stil selbst viele Verbindungen öffnen und schließen. Das sind zum Beispiel Datenbank-Zugriffe von Entwicklern, Fernwartungs-Verbindungen zu Servern oder eben die iMessage-Dauerverbindungen von Photon, wo pro Stunde sehr viele Verbindungen ab- und wieder aufgebaut werden.

Übersetzt heißt das: Der Bug ist in erster Linie ein Problem für Macs, die professionell als Server oder "Dauerläufer" eingesetzt werden. Also zum Beispiel Mac minis, die in Firmen für automatisierte Abläufe genutzt werden, Mac-Server für Mediensammlungen oder Macs, die im Homeoffice die ganze Zeit KI-Modelle ausführen. Für euer normales MacBook zu Hause ist er in der Praxis so gut wie irrelevant.

So prüft ihr euren eigenen Mac

Wer trotzdem mal nachschauen will, wie lange sein Mac schon läuft, kann einfach das Terminal öffnen (zu finden unter Programme > Dienstprogramme) und folgendes eintippen:

uptime

Die Ausgabe zeigt euch, seit wie vielen Tagen der Rechner ohne Neustart läuft.

Wer paranoid ist und den TIME_WAIT-Zähler im Auge behalten will, bekommt mit diesem Befehl die Anzahl der aktuell im TIME_WAIT-Zustand hängenden Verbindungen:

netstat -an | grep TIME_WAIT

Wenn diese Zahl kontinuierlich wächst und die Einträge nach ein paar Minuten nicht wieder verschwinden, habt ihr den Bug tatsächlich erwischt. In aller Regel werdet ihr aber eine überschaubare Zahl sehen, die sich ständig ändert, und das ist vollkommen normal.

Was tun, wenn man betroffen ist?

Für den sehr unwahrscheinlichen Fall, dass ihr den Bug wirklich erwischt, gibt es aktuell nur einen Workaround: Neustart. Das setzt den Zähler zurück auf Null, und alles läuft wieder wie gewohnt. Wer einen Mac als Server betreibt, sollte sich einfach einen regelmäßigen Reboot alle 30 Tage einrichten, dann seid ihr aus dem Schneider.

Ich gehe stark davon aus, dass Apple das Problem spätestens mit macOS 26.5 aus der Welt schafft, sobald der Bug offiziell bei ihnen landet. Es geht hier um ein paar falsche Zeilen Code im Kernel, und das ist für Apple nach eigener Einschätzung von außen betrachtet wirklich kein großes Ding.

Also, aus meiner Sicht ist das ganze für wenige Benutzer ärgerlich, aber kein Weltuntergang, wie einige Zeitungen es hinstellen. Ich hoffe, mein Artikel war halbwegs verständlich und hilft euch, die Sache einzuordnen.

Jens Kleinholz( Gründer & Sir Apfelot )

Seit 2012 betreibe ich meinen Blog als Sir Apfelot und helfe meinen Lesern bei technischen Problemen. In meiner Freizeit flitze ich auf elektrischen Einrädern, fotografiere mit meinem iPhone, klettere in den hessischen Bergen oder wandere mit meiner Familie. Meine Artikel behandeln Apple-Produkte, Drohnen-News und Lösungen für aktuelle Bugs.