MacOS – ath leaves many open sockets

catalinadata synchronizationitunesmacosresources

This seems somehow similar to this question. While diagnosing some weird application behaviour on my MacBook Pro and the dreaded "too many open files" errors appearing in the shell out of nowhere, I came to find out that ath, an executable component of AirTrafficHost.framework, keeps a huge number of open sockets in CLOSE_WAIT state. The number tends to only increase in time until it hits the system limit for open file descriptors. I use my MBP docked most of the time and it is always on, so the limit is reached after a couple of days.

AirTrafficHost.framework is a private Apple framework and seems to be part of the wireless communcation with iOS devices. There are two iOS devices for which I've enabled network sync – an iPad Pro and an iPhone. It seems that ath tries to talk to them and at some point the connection is terminated, but the network sockets are never closed and just keep piling up. lsof shows:

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 ...

Right now, it's been 5 hrs since the last reboot and the number of socket descriptors is already 162 in two ath processes (one for each iOS device, I guess) and growing:

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

It also seems that for each disconnect, there is an entry in /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

The OS is a fully updated macOS Catalina 10.15.3.

Is anyone else seeing the same problem and are you aware of a solution that does not involve increasing the system limits or performing a clean OS install? I already have a launchd job to increase kern.maxfiles and kern.maxfilesperproc, but that's not really a solution – it just postpones the problem. And I'd prefer not to disable network synchronisation, because I'm out of USB ports.

Best Answer

It is actually okay to raise the system limits - for example up to 65536 open files. 162 sockets over 5 hours is a relatively low number. It is not going to affect system performance in any way, and does not use up any kind of significant resources.

Ordinarily sockets will eventually go away by themselves after a timeout. However in your case, they're listed as being in state CLOSE_WAIT. This means that the kernel is waiting for the application to call close() on the socket descriptor, and they will not go away automatically.

ath is supposed to be doing just that - so it seems like you've either hit a bug, or have some kind of serious misconfiguration that makes ath behave incorrectly.

As a temporary measure, you can get the sockets closed by closing the ath process. You can see the process ID in your output from lsof, and then use the kill command to close it up. You can start it again from:

/System/Library/PrivateFrameworks/AirTrafficHost.framework/ath
Related Question