L'athlète laisse de nombreuses prises ouvertes

Cela ressemble en quelque sorte à cette question . Alors que je diagnostiquais un comportement bizarre d'une application sur mon MacBook Pro et les redoutables erreurs "too many open files" apparaissant dans le shell de façon inattendue, j'ai découvert que ath un composant exécutable de AirTrafficHost.framework conserve un nombre important de prises ouvertes dans CLOSE_WAIT l'état. Le nombre tend à augmenter avec le temps jusqu'à atteindre la limite du système pour les descripteurs de fichiers ouverts. J'utilise mon MBP sur une station d'accueil la plupart du temps et il est toujours allumé, donc la limite est atteinte après quelques jours.

AirTrafficHost.framework est un cadre privé d'Apple et semble faire partie de la communication sans fil avec les appareils iOS. Il y a deux appareils iOS pour lesquels j'ai activé la synchronisation réseau - un iPad Pro et un iPhone. Il semble que ath essaie de leur parler et à un moment donné, la connexion est interrompue, mais les sockets réseau ne sont jamais fermés et continuent de s'accumuler. lsof montre :

ath  627 hristo   7u  IPv6 0x2e106590d5ff22b3  0t0  TCP [fe80:5::xxx]:49280->[fe80:5::yyy]:57461 (CLOSE_WAIT)
ath  627 hristo   8u  IPv6 0x2e106590d6aea413  0t0  TCP [fe80:5::xxx]:49300->[fe80:5::yyy]:57464 (CLOSE_WAIT)
ath  627 hristo  10u  IPv6 0x2e106590d7a65c93  0t0  TCP [fe80:5::xxx]:49529->[fe80:5::yyy]:57482 (CLOSE_WAIT)
ath  627 hristo  11u  IPv6 0x2e106590d4fe9a33  0t0  TCP [fe80:5::xxx]:49574->[fe80:5::yyy]:57486 (CLOSE_WAIT)
ath  627 hristo  13u  IPv6 0x2e106590d5feeb93  0t0  TCP [fe80:5::xxx]:49609->[fe80:5::yyy]:57490 (CLOSE_WAIT)
ath  627 hristo  14u  IPv6 0x2e106590d18e7b93  0t0  TCP [fe80:5::xxx]:49656->[fe80:5::yyy]:57494 (CLOSE_WAIT)
... many more ...

Actuellement, cela fait 5 heures depuis le dernier redémarrage et le nombre de descripteurs de socket est déjà de 162 en deux. ath (un pour chaque appareil iOS, je suppose) et ne cesse de croître :

$ lsof -n | grep ^ath | grep TCP | wc -l
    162

Il semble également que pour chaque déconnexion, il y ait une entrée dans le fichier /var/log/system.log :

Mar 17 01:15:23 MacBook-Pro AMPDeviceDiscoveryAgent[433]: Entered:_AMMuxedDeviceDisconnected, mux-device:159
Mar 17 01:15:23 MacBook-Pro AMPDeviceDiscoveryAgent[433]: Entered:__thr_AMMuxedDeviceDisconnected, mux-device:159
Mar 17 01:15:23 MacBook-Pro AMPDeviceDiscoveryAgent[433]: tid:7387 - Mux ID not found in mapping dictionary
Mar 17 01:15:23 MacBook-Pro AMPDeviceDiscoveryAgent[433]: tid:7387 - Can't handle disconnect with invalid ecid

Le système d'exploitation est un MacOS Catalina 10.15.3 entièrement mis à jour.

Quelqu'un d'autre rencontre-t-il le même problème et connaissez-vous une solution qui n'implique pas d'augmenter les limites du système ou d'effectuer une installation propre du système d'exploitation ? J'ai déjà un launchd emploi pour augmenter kern.maxfiles y kern.maxfilesperproc mais ce n'est pas vraiment une solution - cela ne fait que repousser le problème. Et je préférerais ne pas désactiver la synchronisation réseau, car je n'ai plus de ports USB.