One Possible Explanation for Some iTunes Sync Problems

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.

20 thoughts on “One Possible Explanation for Some iTunes Sync Problems

  1. I can’t pretend that I understood all you’ve written here, but I do get the drift. As I’ve said before I’m not having sync problems, but I know many others who have/do. I have just 2 iOS devices, both my own, with no family or friends syncing to my library. I only ever sync over direct lightening/usb, never wifi, as I found it too slow. I download all apps, updates, media etc to my computer, then sync by wire.

    I also have a habit of shutting down my rMacbook Pro at least weekly. This is a pattern I’ve always followed, so as to wipe it down, clean it externally and dump accrewed ‘junk’ that builds up internally from daily operating processes. I read about this being a good practice to follow, somewhere about 4 years or more ago. Anyway, from what your reporting, I’ll keep to my habits on this for now.

    • I agree. Just because we can leave our computers running (or asleep) for weeks at at time doesn’t mean it’s a good idea to do so.

        • Apparently there is, at least for iTunes syncs. I think it’s a good idea to reboot more frequently; it gets rid of VM files, caches, etc.

      • I’m kinda old-fashioned…or maybe just old. My MacBook and two Mac minis usually get shutdown every night…but I still have trouble with wired syncs (the post below). Oh wait! I’m helping the environment! Yeah, that’s it. 🙂

        • The issue I’m discussing here affects wi-fi syncs, not wired syncs. There are plenty of other sync issues.

  2. I can’t pretend that I understood all you’ve written here, but I do get the drift. As I’ve said before I’m not having sync problems, but I know many others who have/do. I have just 2 iOS devices, both my own, with no family or friends syncing to my library. I only ever sync over direct lightening/usb, never wifi, as I found it too slow. I download all apps, updates, media etc to my computer, then sync by wire.

    I also have a habit of shutting down my rMacbook Pro at least weekly. This is a pattern I’ve always followed, so as to wipe it down, clean it externally and dump accrewed ‘junk’ that builds up internally from daily operating processes. I read about this being a good practice to follow, somewhere about 4 years or more ago. Anyway, from what your reporting, I’ll keep to my habits on this for now.

    • I agree. Just because we can leave our computers running (or asleep) for weeks at at time doesn’t mean it’s a good idea to do so.

        • Apparently there is, at least for iTunes syncs. I think it’s a good idea to reboot more frequently; it gets rid of VM files, caches, etc.

      • I’m kinda old-fashioned…or maybe just old. My MacBook and two Mac minis usually get shutdown every night…but I still have trouble with wired syncs (the post below). Oh wait! I’m helping the environment! Yeah, that’s it. 🙂

        • The issue I’m discussing here affects wi-fi syncs, not wired syncs. There are plenty of other sync issues.

  3. I think Apple have screwed up the networking in Yosemite, and badly. They’ve implemented numerous changes and have not fully tested them. I am currently stuck on Mavericks for work because of the mess they’ve made with VPN access — I work from home and have to VPN in to work ro see our development and QA servers. Suddenly, with Yosemite, I can’t get at them.

    Having used Carbon Copy Cloner to backup before I upgraded, I booted off the backup disk and, voila! There were the servers. Nothing had changed. After much research (of other people’s more technical research), I discovered that Apple had altered the way OS X identifies .local domains.

    The long version is that .local domains are reserved for multicast DNS, but years back, Microsoft TechNet docs on setting up intranets used .local domains as examples. While the practice of using .local for Microsoft intranet addresses is incorrect, it is in common use. Yes, it breaks with standards, but it’s a real-life situation which should be allowed for.

    Apple uses .local for Bonjour, naming the other Macs and Apple devices on your local network. This is an acceptable use, according to standards. Up until recently, the way OS X looked for .local domains in a manner which discovered Microsoft network .local addresses first, then found Apple devices via Bonjour. With Yosemite, OS X checks for Apple .local domains, and if the .local isn’t a Bonjour computer, looks no further.

    Strictly speaking, Apple have implemented the system correctly. Good for them! Sadly, this breaks the expected behavior and means users who have to interact with an intranet of the Microsoft variety may well be unable to do so. I can’t imagine that’s a small number of people.

    As with the iTunes Sync issue, also related to networking, there’s a command line command to change the behaviour (‘sudo discoveryutil mdnsactivedirectory yes’), but this is unsustainable. When fighting an IT department who didn’t want Apple computers on their network in the first place, telling them every user will need to drop to the command line and enter some technical looking code, just so the computer works as expected, doesn’t fly.

  4. I think Apple have screwed up the networking in Yosemite, and badly. They’ve implemented numerous changes and have not fully tested them. I am currently stuck on Mavericks for work because of the mess they’ve made with VPN access — I work from home and have to VPN in to work ro see our development and QA servers. Suddenly, with Yosemite, I can’t get at them.

    Having used Carbon Copy Cloner to backup before I upgraded, I booted off the backup disk and, voila! There were the servers. Nothing had changed. After much research (of other people’s more technical research), I discovered that Apple had altered the way OS X identifies .local domains.

    The long version is that .local domains are reserved for multicast DNS, but years back, Microsoft TechNet docs on setting up intranets used .local domains as examples. While the practice of using .local for Microsoft intranet addresses is incorrect, it is in common use. Yes, it breaks with standards, but it’s a real-life situation which should be allowed for.

    Apple uses .local for Bonjour, naming the other Macs and Apple devices on your local network. This is an acceptable use, according to standards. Up until recently, the way OS X looked for .local domains in a manner which discovered Microsoft network .local addresses first, then found Apple devices via Bonjour. With Yosemite, OS X checks for Apple .local domains, and if the .local isn’t a Bonjour computer, looks no further.

    Strictly speaking, Apple have implemented the system correctly. Good for them! Sadly, this breaks the expected behavior and means users who have to interact with an intranet of the Microsoft variety may well be unable to do so. I can’t imagine that’s a small number of people.

    As with the iTunes Sync issue, also related to networking, there’s a command line command to change the behaviour (‘sudo discoveryutil mdnsactivedirectory yes’), but this is unsustainable. When fighting an IT department who didn’t want Apple computers on their network in the first place, telling them every user will need to drop to the command line and enter some technical looking code, just so the computer works as expected, doesn’t fly.

  5. I use a wire to sync my iPad (was a 2 and an Air, but now just Air, and all have had trouble over the years, including a 4G iPod touch running iOS6). Most of my sync hangups happen when I’ve done something with songs. By accident I ended up on two threads in the Apple discussions. One where iTunes is randomly losing tracks from albums (it seems like mostly from CDs you’ve imported), and one about the sync never finishing. They may be related. One “fix” for the sync not finishing is to use something like iExplorer to delete the file iTunes_Control/iTunes/MediaLibrary.sqlitedb on the iPhone/iPad and reboot the phone/pad. The theory is that that file thinks that a particular song on the phone/pad should also be in iTunes on your Mac, and when that song has been ‘rubbed out’ by iTunes the sync function gets upset. No doubt about it it sync’ing is hard, especially when you can add or remove stuff from either end of the wire. If iTunes (or someone) is just deleting songs without doing the paperwork for a proper removal then I can see where that would cause trouble, but that shouldn’t hang things up.

  6. I use a wire to sync my iPad (was a 2 and an Air, but now just Air, and all have had trouble over the years, including a 4G iPod touch running iOS6). Most of my sync hangups happen when I’ve done something with songs. By accident I ended up on two threads in the Apple discussions. One where iTunes is randomly losing tracks from albums (it seems like mostly from CDs you’ve imported), and one about the sync never finishing. They may be related. One “fix” for the sync not finishing is to use something like iExplorer to delete the file iTunes_Control/iTunes/MediaLibrary.sqlitedb on the iPhone/iPad and reboot the phone/pad. The theory is that that file thinks that a particular song on the phone/pad should also be in iTunes on your Mac, and when that song has been ‘rubbed out’ by iTunes the sync function gets upset. No doubt about it it sync’ing is hard, especially when you can add or remove stuff from either end of the wire. If iTunes (or someone) is just deleting songs without doing the paperwork for a proper removal then I can see where that would cause trouble, but that shouldn’t hang things up.

  7. Glad for the in-depth write-up on the main page vs. the comment on the other article. But just to clarify, usbmuxd also handles local USB sync. So if you get the “iTunes could not connect to this iPhone. This device is no longer connected.” error message when trying local USB sync, that’s usbmuxd failing. Kill usbmuxd and syncing with that device will work again (for a while).

    That said, iTunes 12.1 just came out with “performance improvements” for device sync. So here’s hoping it’s a much needed fix for this and other issues.

  8. Glad for the in-depth write-up on the main page vs. the comment on the other article. But just to clarify, usbmuxd also handles local USB sync. So if you get the “iTunes could not connect to this iPhone. This device is no longer connected.” error message when trying local USB sync, that’s usbmuxd failing. Kill usbmuxd and syncing with that device will work again (for a while).

    That said, iTunes 12.1 just came out with “performance improvements” for device sync. So here’s hoping it’s a much needed fix for this and other issues.

  9. I know this is an older post, but just as an FYI about the breadth of the problem with CLOSE_WAIT connections – this is also an (as yet un-acknowledged) issue with iCloud on every version of Windows. A new connection on a new port is opened every 10 minutes – so that’s 144 new connections per day, until you run out of ports and your network connection completely stops working.
    https://discussions.apple.com/message/27776730

  10. I know this is an older post, but just as an FYI about the breadth of the problem with CLOSE_WAIT connections – this is also an (as yet un-acknowledged) issue with iCloud on every version of Windows. A new connection on a new port is opened every 10 minutes – so that’s 144 new connections per day, until you run out of ports and your network connection completely stops working.
    https://discussions.apple.com/message/27776730

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.