macOS’ta ilginç bir çekirdek hatası, sistemi 49 gün 17 saat 2 dakika 47 saniye boyunca hiç kapatmadan çalıştırdığınızda yeni ağ bağlantılarını kurmayı engelleyebiliyor. Sorunun kaynağı, XNU çekirdeğinde TCP zaman damgalarını “sistem açıldığından beri geçen milisaniye” olarak tutan 32 bitlik bir sayacın taşması. Hata ilk olarak iMessage izleme amaçlı çok sayıda Mac çalıştıran Photon ekibinin saha gözlemleri ve tersine mühendisliğiyle ortaya çıktı.
Sorunun kaynağı
TCP/IP yığınının içinde “tcp_now” adıyla tutulan sayaç 32 bit olduğu için 4.294.967.295’e ulaştığında sıfıra sarıyor. macOS’ta bu sarma anından sonra TCP zaman damgası saati fiilen “donuyor” ve çekirdeğin bağlantıları temizleyip kapatan mantığı taşmalı hesap yüzünden çalışamaz hale geliyor. Sonuçta TIME_WAIT durumundaki bağlantılar beklenenden uzun süre tutuluyor, geçici (ephemeral) portlar doluyor ve yeni TCP bağlantıları kurulamıyor. Mevcut açık akışlar bir süre çalışmaya devam edebildiği için sorun ilk bakışta “internet gitti” gibi görünmeyebilir; örneğin ping (ICMP) genelde yanıt verirken Safari’de yeni sekmeler açılmaz veya SSH gibi yeni oturumlar zaman aşımına uğrar.
Bu davranış, RFC 7323’te tanımlanan TCP Zaman Damgası uzantısının taşma anındaki doğru yönetimiyle çelişiyor; standart, sayaç sınırına gelindiğinde nasıl davranılması gerektiğini açıkça belirtirken macOS’taki uygulamanın hatalı olduğu anlaşılıyor.
Kimleri etkiliyor, ne yapmalı?
Günlük kullanıcılar genelde güncellemeler veya kapat–aç döngüleri nedeniyle 49,7 güne ulaşmadığı için bu hatayla karşılaşmayabilir. Ancak Mac mini gibi cihazları sunucu veya otomasyon amaçlı haftalarca açık tutanlar, yoğun bağlantı trafiği nedeniyle port havuzunu hızla doldurup sorunu belirgin şekilde yaşayabiliyor.
Şu an için pratik çözüm basit: yeniden başlatma. Sistem yeniden başlayınca tcp_now sıfırlanıyor ve sayaç yeniden saymaya başlıyor. Photon, çekirdek hatasını tetikleyen koşulu hedef alan bir geçici yöntem üzerinde çalıştığını söylese de Apple’dan resmi bir yama paylaşılmadı. Etkilenme riskini azaltmak için uptime’ı takip edip 49 güne yaklaşmadan planlı yeniden başlatma yapmak mantıklı. Terminal’de “uptime” komutuyla çalışma süresini hızlıca görebilirsiniz.
Benzer taşma sorunları daha önce de görülmüştü: Windows 95/98’in ünlü “49,7 gün” kilitlenmesi ve 2038’de 32 bit zamanın taşması (Y2K38) aynı sınıfta yazılım hatalarına örnek gösteriliyor.
Kaynak: www.techspot.com
