Ce s-a întâmplat: pe scurt
Pe 9 aprilie 2026, echipa Photon (companie ce dezvoltă un framework pentru agenți software conectați la platforme de mesagerie) a publicat un raport detaliat: „We Found a Ticking Time Bomb in macOS TCP Networking". Au descoperit bug-ul pe propria flotă de servere de monitorizare iMessage și au reușit să-l reproducă pe alte 2 mașini. Trasarea problemei i-a dus la o singură linie de cod în XNU kernel: comparația care decide când o conexiune TCP în starea TIME_WAIT poate fi închisă.
Descoperire publică: 9 aprilie 2026, de către Photon
Photon: o companie care dezvoltă un framework pentru agenți software conectați la platforme de mesagerie, a observat bug-ul pe propria flotă de monitorizare iMessage și l-a reprodus pe alte 2 mașini. Au tras totul la o singură comparație în codul-sursă XNU (kernelul macOS).
Pragul exact: 49 de zile, 17 ore, 2 minute, 47 de secunde
După atâtea uptime continuu, un counter pe 32 de biți din kernel face overflow și „îngheață" ceasul intern de timestamp TCP. Practic, e exact 2³² milisecunde (4.294.967.295 ms ≈ 49,71 zile): limita matematică a unui unsigned int 32-bit. Bug clasic de overflow.
Simptomele: TCP cade, ping merge
După prag, conexiunile în starea TIME_WAIT nu mai expiră, porturile efemere se epuizează una câte una, iar Mac-ul nu mai poate stabili niciun TCP connection nou. Browsing-ul, email-ul, SSH, sync-ul iCloud, toate cad. ICMP (ping-ul) continuă să meargă, deci diagnosticul superficial spune „are net".
Apple n-a confirmat (încă)
Niciun comunicat oficial, niciun feedback ID public, fix-ul nu apare în macOS 26.4.1 (lansat aprilie 2026). Comunitatea așteaptă fix în 26.5, nu confirmat. Adam Engst (TidBITS) n-a găsit nicio discuție pe Apple Developer Forums.
Mecanismul tehnic: ce face overflow-ul
Kernelul XNU (folosit de macOS, iOS și watchOS, dar implementarea TCP diferă pe Mac) ține un counter intern de timestamp pentru fiecare conexiune TCP, folosit ca să decidă când o conexiune în starea TIME_WAIT poate fi „uitată" și resursele eliberate. Counter-ul e stocat ca unsigned 32-bit integer, în milisecunde de la pornirea sistemului.
Math-ul: 2³² milisecunde = 4.294.967.296 ms ÷ 1000 = 4.294.967 secunde ÷ 86.400 (secunde/zi) ≈ 49,71 zile. La acel moment exact (49 zile, 17 ore, 2 minute, 47 secunde), counter-ul wrapped la 0. Logica de cleanup care zice „dacă timestamp-ul vechi al conexiunii + 60 secunde < timpul curent, închide conexiunea" devine permanent falsă, pentru că timpul curent (resetat la 0) e mereu mai mic decât timestamp-ul vechi.
Consecința: vechile conexiuni TIME_WAIT nu mai sunt curățate niciodată. Fiecare nouă conexiune deschidită ocupă un port efemer din pool (49152-65535 pe macOS = ~16.000 disponibile). În câteva zile pe un sistem activ, pool-ul se golește. Mac-ul rămâne fără porturi efemere → orice nouă conexiune TCP eșuează. Browser-ul vede „connection refused" sau timeout, deși Wi-Fi-ul arată conectat și ping-ul către google.com merge perfect.
Stats tehnice: sumar
| Trigger uptime | 49 zile, 17h, 2m, 47s |
| Cauză tehnică | Overflow uint32 în kernel XNU |
| Math underlying | 2³² ms ≈ 4,29 mld milisecunde |
| Versiuni confirmate | macOS 26 (Tahoe): posibil și Catalina |
| Ce se rupe | Conexiuni TCP noi (TIME_WAIT nu expiră) |
| Ce continuă să meargă | ICMP / ping |
| Fix imediat | Reboot: counter-ul resetează |
| Fix Apple oficial | Așteptat în macOS 26.5 (neconfirmat) |
Cine e afectat real
Pragul de 49 de zile pare mare, dar e fezabil pentru categorii specifice de utilizatori. Iată cine ar trebui să fie atent și cine poate ignora bug-ul fără frică:
Mac servers care nu se reboot-ează
Cea mai expusă categorie. Mac mini sau Mac Studio configurat ca server de fișiere, build server, server media, care merge luni de zile fără pauză. Aici uptime-ul de peste 49 de zile e norma, nu excepția.
Mac mini ca AI bench / inference server
Trend recent: Mac mini cu 64GB RAM unified folosit pentru rulat modele AI local (Ollama, LM Studio). Lăsat zile în șir cu sesiuni active. Categoric afectat.
Workstații dev pe proiecte lungi
Programatori care nu închid Mac-ul săptămâni întregi pentru că au environment de dezvoltare complex (multi-tab, IDE-uri, simulatoare, container-e Docker). Reboot înseamnă ore de re-setup. Mulți preferă să-l țină pornit.
Useri obișnuiți: NU sunt afectați practic
Pe un MacBook obișnuit, security updates apar o dată la 3-6 săptămâni și forțează reboot. Plus că laptop-urile dorm zilnic: sleep-ul nu contribuie la uptime în același ritm. Pragul de 49 de zile e foarte greu de atins.
Cum verifici și cum repari: 5 pași
Procesul e banal: Terminal, o comandă, eventual un reboot. Sub 5 minute total.
Deschide Terminal
Spotlight (Cmd+Space) → tipărește „Terminal" → Enter. Sau Aplicații → Utilitare → Terminal.
Tipărește comanda uptime și apasă Enter
Comanda exactă: uptime. Vei vedea ceva de forma „16:42 up 23 days, 5:14, 3 users, load average...". Numărul de „days" e cât a stat aprins Mac-ul de la ultimul reboot.
Compară cu pragul de 49 zile
Sub 30 zile: total în siguranță. Între 30-45 zile: fii atent, programează un reboot. Între 45-49 zile: reboot urgent. Peste 49 zile: probabil deja ai simptome (browser care nu mai încarcă, app-uri care eșuează la conexiune, deși ping merge).
Reboot complet (nu doar logout/sleep)
Apple → Restart. NU folosi „Sleep" sau „Logout": counter-ul kernel rămâne activ. Doar un reboot full sau shutdown + start resetează counter-ul TCP timestamp.
Pentru Mac servers: programează reboot lunar
Dacă folosești Mac-ul ca server permanent, setează un reboot automat lunar (sub 30 zile interval). Se poate face cu launchd / cron sau prin Energy Saver → Schedule. Asta elimină riscul indiferent dacă Apple lansează fix-ul sau nu.
Context istoric: bug-ul ăsta nu e nou în computing
Overflow-ul de counter pe 32-bit la ~49,7 zile e o clasă întreagă de bug-uri care a afectat sisteme operaționale și echipamente de rețea timp de decenii. Apple nu e prima victimă, și probabil nici ultima.
Windows 95
Bug aproape identic: counter de uptime pe 32-bit, crash la ~49,7 zile. Microsoft a recunoscut public și a lansat patch în 1999. Devenise meme între sysadmin-i.
VAX/VMS (Digital Equipment, anii '80)
Counter pe 32-bit dar în zecimi de milisecundă, overflow la ~497 zile. Mai rar întâlnit pentru că nimeni nu păstra un VAX pornit atâta timp fără pauze de mentenanță.
Cisco IOS (anumite versiuni)
Bug similar de overflow uptime care afecta routere de production. Reboot programat la fiecare 24 zile devenise practica standard în multe data centers.
Lecția pentru Apple: bug-ul ar fi putut fi prevenit cu un counter pe 64-bit (limită ~584 milioane de ani: practic infinit) sau cu logică explicită de wrap-around. Faptul că un sistem operațional modern încă folosește uint32 pentru counter-uri de timp e o decizie surprinzătoare în 2026.
Atenție: dacă reboot-ul NU rezolvă, e altă problemă
Dacă ai făcut reboot și Mac-ul tot are probleme, sau, mai grav, MacBook-ul tău M2/M3 nu mai pornește deloc după un update macOS Tahoe, nu e bug-ul de 49 de zile. E posibil să fii afectat de bug-ul Tahoe Bricked Fix, complet diferit, care brick-uiește placa de bază a MacBook-urilor M2 și M3 după update-ul la macOS 26.4 / 26.4.1. DFU Revive eșuează, Apple Configurator dă erori 4013/4014. Acest bug NU se repară prin reboot: necesită intervenție de service la nivel firmware. Noi îl reparăm în 24h, păstrăm placa originală și datele tale. Citește ghidul complet aici.
✓ Bug-ul Tahoe Bricked (MacBook M2/M3 mort după update): articolul nostru tehnic, reparație în 24h.
✓ Alte probleme post-update: diagnostic gratuit, ne suni la 0739.795.800.
Întrebări frecvente
Cum știu sigur dacă am bug-ul de 49 de zile sau e altceva?
Sleep contează ca uptime?
macOS 26.4.1 a reparat bug-ul?
Versiunile mai vechi de macOS sunt afectate?
Pot face ceva preventiv în afară de reboot?
Ce face Radical Service în acest caz?
Bug-ul ăsta afectează și iPhone, iPad sau Apple Watch?
Există vreun risc real (loss of data, hardware damage)?
Surse
- Photon (sursa primară): We Found a Ticking Time Bomb in macOS TCP Networking (raport tehnic complet, cu referință directă la linia din XNU)
- TidBITS: Why the macOS „49-Day" Networking Bug Probably Won't Affect You (Adam Engst, 9 aprilie 2026)
- Six Colors: Macs crash after 49 days of uptime?
- Daring Fireball: MacOS Seemingly Crashes After 49 Days of Uptime, a „Feature" Perhaps Exclusive to Tahoe
- AppleInsider: Unless you reboot every once in a while, your Mac will get kicked offline every 49 days
- Michael Tsai: Tahoe TCP Overflow Bug (sugerează posibilă origine în macOS 10.15 Catalina)