iTunes syncing is broken, and Apple’s not doing a good job of fixing it. There are some problems that seem well-documents, such as duplicate purchased tracks causing sync issues, and others that are too vague to find a cause.

One issue that has been discussed on Apple’s support forums seems to be caused by some incorrect handling of network activity by OS X. It seems that iTunes – or, more correctly, the usbmuxd process that handles connections between a Mac and and iOS device – has some problems. This process opens network connections to the iOS device in order to communicate with it. It opens two connections, one using IPv4 and another with IPv6, over TCP, to port 62078. If you run a command in Terminal, you can see how many connections are open.

$ netstat -an | grep 62078 | head

tcp4 0 0 192.168.1.97.50112 192.168.1.129.62078 CLOSE_WAIT

tcp6 0 0 fe80::8a63:dfff:.50111 fe80::103a:1133:.62078 CLOSE_WAIT

The above Terminal output is what I saw after I turned on Wi-Fi syncing for my iPhone. A bit later, I ran the command again, and, instead of two lines, there were four. A bit later, just at the beginning of a sync, I ran the command and saw this:

tcp6 0 0 fe80::8a63:dfff:.50394 fe80::103a:1133:.62078 ESTABLISHED

tcp4 0 0 192.168.1.97.50393 192.168.1.129.62078 ESTABLISHED

tcp4 0 0 192.168.1.97.50221 192.168.1.129.62078 CLOSE_WAIT

tcp6 0 0 fe80::8a63:dfff:.50220 fe80::103a:1133:.62078 CLOSE_WAIT

tcp4 0 0 192.168.1.97.50145 192.168.1.129.62078 CLOSE_WAIT

tcp6 0 0 fe80::8a63:dfff:.50144 fe80::103a:1133:.62078 CLOSE_WAIT

tcp4 0 0 192.168.1.97.50112 192.168.1.129.62078 CLOSE_WAIT

tcp6 0 0 fe80::8a63:dfff:.50111 fe80::103a:1133:.62078 CLOSE_WAIT

In this case, there are two ESTABLISHED connections, which are open and active, and the remainder are in CLOSE_WAIT state, which means that iTunes (or, more correctly, the usbmuxd process) sent a FIN command to the device, and is waiting for an ACK to close the connection. (See this diagram to understand TCP connection states.)

What seems to happen is that some users get “too many open files” errors in system.log (you can view this in the Console app), which causes syncing to fail.

There are two solutions to this problem. The easiest is just to restart your Mac. Quitting iTunes won’t solve this issue; the usbmuxd is part of the MobileDevice framework. Restarting your Mac will clear all these connections, however.

The second is to kill the process using Activity Monitor, or Terminal. In the former, find usbmuxd, select it, then click the X button at the top-left of the window, then click Force Quit.

If you want to do this via Terminal, run this command:

ps ax | grep usbmuxd

You’ll get a process number at the beginning of the line as the result of the command. Then run this command, using the process number in place of the XX:

sudo kill XX

You’ll need to enter your administrator password.

This is clearly something that shouldn’t be happening, and it seems to happen in two cases. The first, as a poster to the Apple forum pointed out, is having multiple iOS devices. In his case, there are “various other iPhones and iPads that my wife and I have around the house,” which may contribute to the number of devices that are getting network connections to the Mac. The Terminal output he includes in the thread show different MAC addresses, therefore different devices.

The second could simply be because you haven’t restarted your Mac in a long time. At the time of this writing, my Mac’s uptime is over 9 days; this is pretty common, since we no longer need to restart for most app updates, and even some OS updates. So it’s a good idea to restart your Mac more often, if only to clean up some of this gunk.

Granted, this shouldn’t happen, no matter what; you shouldn’t have to restart your Mac to get iTunes to work. It’s worth noting, however, that this isn’t a new issue; if you Google “too many open files iTunes,” you’ll see people reporting this problem as far back as 2012. This is a complex issue, and a complicate solution; if you don’t understand networking, you probably haven’t understood much of this article (assuming you even read past the first couple of paragraphs).

Thanks to Mike for pointing this issue out in a comment to this article.