Un chercheur a découvert un comportement surprenant sur certains Mac qui restent allumés en continu, et cette découverte mérite votre attention si vous exploitez des machines comme serveurs ou pour faire tourner des agents d’intelligence artificielle. Le problème se manifeste après une période très précise de fonctionnement ininterrompu et affecte la création de nouvelles connexions réseau, ce qui peut paralyser des services critiques. Dans cet article, nous expliquons l’origine technique du bug, comment le repérer et quelles mesures simples permettent de le contourner pour protéger vos systèmes.
Quel est exactement le dysfonctionnement observé?
Des ingénieurs ont remarqué que, passé un délai précis de fonctionnement continu, certains Mac cessaient d’établir de nouvelles connexions TCP. Les connexions déjà actives continuaient de fonctionner et le ping répondait encore, mais toute tentative d’ouvrir une nouvelle session réseau échouait systématiquement. Ce comportement surprenant a été identifié sur des machines utilisées comme serveurs, où le redémarrage n’intervient que rarement.
Le symptôme principal ressemble à un blocage des requêtes sortantes qui créent de nouvelles sessions TCP. Les services dépendant d’un nouvel handshake réseau subissaient des interruptions, alors que les opérations en cours restaient intactes. Les administrateurs ont d’abord pensé à une panne matérielle ou à une anomalie de configuration réseau avant de remonter au véritable coupable.
Une simple réinitialisation du système a permis de restaurer immédiatement le fonctionnement normal. Cette solution, bien que simple, n’empêche pas le bug de réapparaître si la machine dépasse à nouveau la durée critique de fonctionnement continu.
Pourquoi le noyau XNU cause-t-il ce problème après 49 jours?
Le cœur du problème tient à la façon dont le noyau XNU horodate les événements réseau en comptant les millisecondes depuis le démarrage avec un entier non signé sur 32 bits. La valeur maximale représentable par ce compteur correspond précisément à 2³² − 1 millisecondes. Lorsqu’elle est atteinte, le compteur revient à zéro et le mécanisme d’horodatage des connexions TCP devient incohérent.
La durée associée à cet overflow est de 49 jours, 17 heures, 2 minutes et 47,296 secondes. Ce basculement provoque des anomalies dans le protocole TCP lorsque le système tente de générer des timestamps pour de nouvelles connexions. Les couches supérieures du réseau interprètent alors mal les délais et rejettent les tentatives d’établissement de session.
| Paramètre | Valeur | Conséquence |
|---|---|---|
| Type de compteur | Entier non signé 32 bits | Repli à zéro après overflow |
| Seuil | 2³² − 1 ms | Environ 49,7 jours |
| Impact | Connexions TCP nouvelles | Échecs d’établissement de session |
| Remède immédiat | Redémarrage | Restauration temporaire du service |
Comment détecter et corriger cette anomalie?
La détection passe par la surveillance fine des tentatives d’ouverture de connexions et par l’analyse des logs réseau. Les indicateurs les plus parlants sont les erreurs répétées sur les nouvelles connexions TCP associées à des timestamps incohérents. Les outils de monitoring réseau permettent d’alerter avant qu’un service critique ne soit perturbé.
Plusieurs actions pratiques permettent de réduire le risque de panne :
- Programmer des redémarrages planifiés avant d’atteindre la barre des 49 jours.
- Mettre à jour le système et le noyau dès qu’un correctif officiel est disponible.
- Isoler les machines servant d’hôtes pour agents IA et prévoir des bascules automatiques.
Ce bug change-t-il la manière d’utiliser un Mac comme serveur pour l’IA?
Les nouveaux usages liés à l’IA encouragent de plus en plus à maintenir des Mac allumés en permanence pour héberger des modèles ou des agents autonomes. Dans ce contexte, la limite de fonctionnement continu devient une contrainte réelle. Vous pourriez rencontrer l’anomalie plus souvent si vos machines exécutent des charges persistantes sans redémarrage.
La nature insidieuse de ce bug explique pourquoi il a échappé aux tests classiques. Les cycles de validation ne couvrent pas toujours des périodes supérieures à cinquante jours, et la logique du code semblait saine à la relecture. En production, la confusion initiale peut conduire les équipes à diagnostiquer le problème comme une défaillance réseau plutôt que comme un overflow du compteur.
Il est donc pertinent de revoir vos procédures opérationnelles si vous exploitez des Mac comme serveurs. Un plan de maintenance préventif combiné à une surveillance robuste réduira l’exposition au risque et garantira la continuité des services.
