com.apple.AddressBook.InternetAccountsBridge[2010]: dnssd_clientstub ConnectToServer: connect() failed path:/var/run/mDNSResponder Socket:4 Err:-1 Errno:1 Operation not permitted

That's the exact same error that I am seeing. DiscoveryD was introduced then dropped for mDNSResponder in 10.10.4. I wonder if it's some hangover from that.

Bloody annoying is what it is!

I have the same issue with AddressBook on 2 Macs syncing to the same IMAP server. This worked perfectly over 4-5 years. For a couple of months, I now have this annoying timeouts when editing my address book.

I sync 3 accounts with one CardDAV server. Sync as such works fine. All changes done (after waiting for the timeouts) are properly updated and synced to my other Mac, my iPhone and iPad. So the network connection as such is fine and the configured address is reachable.

When editing one address book entry, the log file creates 3 attempts of the following entries, repeated 6 times; a total of 18 timeouts (the number of the 6 repeats is probably dependent on the number of details of one address book entry). Details of the log file are as follows:

19/12/15 01:29:10.323 com.apple.AddressBook.InternetAccountsBridge[5125]: dnssd_clientstub ConnectToServer: connect()-> No of tries: 3

19/12/15 01:29:10.341 sandboxd[137]: ([5125]) com.apple.Addres(5125) deny network-outbound /private/var/run/mDNSResponder

19/12/15 01:29:11.328 com.apple.AddressBook.InternetAccountsBridge[5125]: dnssd_clientstub ConnectToServer: connect() failed path:/var/run/mDNSResponder Socket:4 Err:-1 Errno:1 Operation not permitted

Details of the 2nd entry are as follows:

com.apple.Addres(5125) deny network-outbound /private/var/run/mDNSResponder

Process: com.apple.Addres [5125]

Path: /System/Library/Frameworks/AddressBook.framework/Versions/A/XPCServices/com.apple.AddressBook.InternetAccountsBridge.xpc/Contents/MacOS/com.apple.AddressBook.InternetAccountsBridge

Load Address: 0x10d717000

Identifier: com.apple.AddressBook.InternetAccountsBridge

Version: 1679.4 (9.0)

Build Info: 1-AddressBook_frameworks_64bit~1679004000000000

Code Type: x86_64 (Native)

Parent Process: launchd [1]

Date/Time: 2015-12-19 01:29:10.324 +0100

OS Version: Mac OS X 10.11.2 (15C50)

Report Version: 8

Thread 0:

0 libsystem_kernel.dylib 0x00007fff87b2a65e __connect_nocancel + 10

1 libsystem_dnssd.dylib 0x00007fff9704aac0 DNSServiceQueryRecord + 61

2 InternetAccounts 0x00007fff90654688 -[IADNSService beginQuerySync] + 636

3 InternetAccounts 0x00007fff90624340 +[IAAccount aListPluginIDForSettings:] + 1705

4 com.apple.AddressBook.InternetAccountsBridge 0x000000010d7182e9

5 CoreFoundation 0x00007fff85cfc17c __invoking___ + 140

6 CoreFoundation 0x00007fff85cfbfce -[NSInvocation invoke] + 286

7 Foundation 0x00007fff94f5fcdf __NSXPCCONNECTION_IS_CALLING_OUT_TO_EXPORTED_OBJECT__ + 17

8 Foundation 0x00007fff94f5f5d9 -[NSXPCConnection _decodeAndInvokeMessageWithData:] + 1123

9 Foundation 0x00007fff94f5f0a7 message_handler + 705

10 libxpc.dylib 0x00007fff96e65396 _xpc_connection_call_event_handler + 35

11 libxpc.dylib 0x00007fff96e6500f _xpc_connection_mach_event + 2198

12 libdispatch.dylib 0x00007fff948834ca _dispatch_client_callout4 + 9

13 libdispatch.dylib 0x00007fff9488393c _dispatch_mach_msg_invoke + 555

14 libdispatch.dylib 0x00007fff94880134 _dispatch_queue_drain + 1207

15 libdispatch.dylib 0x00007fff94882293 _dispatch_mach_invoke + 735

16 libdispatch.dylib 0x00007fff94880134 _dispatch_queue_drain + 1207

17 libdispatch.dylib 0x00007fff9488663b _dispatch_queue_invoke + 549

18 libdispatch.dylib 0x00007fff9487b33f _dispatch_client_callout + 8

19 libdispatch.dylib 0x00007fff9487f1cf _dispatch_root_queue_drain + 1890

20 libdispatch.dylib 0x00007fff9487ea34 _dispatch_worker_thread3 + 91

21 libsystem_pthread.dylib 0x00007fff8b5ca68f _pthread_wqthread + 1129

22 libsystem_pthread.dylib 0x00007fff8b5c8365 start_wqthread + 13

Binary Images:

0x10d717000 - 0x10d718fff com.apple.AddressBook.InternetAccountsBridge (9.0 - 1679.4) <b81763bd-9e7e-377c-b3a2-1c3074c3ce6e> /System/Library/Frameworks/AddressBook.framework/Versions/A/XPCServices/com.apple.AddressBook.InternetAccountsBridge.xpc/Contents/MacOS/com.apple.AddressBook.InternetAccountsBridge

0x7fff85cc3000 - 0x7fff86139fff com.apple.CoreFoundation (6.9 - 1256.14) <068d1ba9-3859-34c7-986a-97edf739c5c8> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation

0x7fff87b14000 - 0x7fff87b32fff libsystem_kernel.dylib (3248.20.55) <0e688457-4915-36dd-8798-5c2edee3f1a3> /usr/lib/system/libsystem_kernel.dylib

0x7fff8b5c7000 - 0x7fff8b5d0ff7 libsystem_pthread.dylib (138.10.4) <327cecd0-b881-3153-8fcc-4fd4818b7f16> /usr/lib/system/libsystem_pthread.dylib

0x7fff90620000 - 0x7fff90689fff com.apple.framework.internetaccounts (2.1 - 210) <ecb2be85-fd74-3fd0-9f14-b0ab713b3acd> /System/Library/PrivateFrameworks/InternetAccounts.framework/Versions/A/InternetAccounts

0x7fff94879000 - 0x7fff948a6fff libdispatch.dylib (501.20.1) <324c9189-2af3-3356-847f-6f4ce1c6e901> /usr/lib/system/libdispatch.dylib

0x7fff94ee8000 - 0x7fff9523cff7 com.apple.Foundation (6.9 - 1256.1) <66106cc9-9d97-3846-88d8-4bf6bb508296> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation

0x7fff96e5e000 - 0x7fff96e87fff libxpc.dylib (756.20.4) <61ab4610-9304-354c-9e9b-d57198ae9866> /usr/lib/system/libxpc.dylib

0x7fff97047000 - 0x7fff9704fffb libsystem_dnssd.dylib (625.20.4) <945b5fb1-da91-3d45-a961-a8fad53c1e7e> /usr/lib/system/libsystem_dnssd.dylib

https://bugreport.apple.com/ The more people that report this issue the higher the chance this gets addressed and the more evidence is available the issue is affecting every user using the address book (perhaps under certain conditions).

Same problem for me since upgrade to 10.11.2. I need to do more test but i think my iOS devices in version 9.2 have problem to.

i have upgrade server and client. Don't if problem come from server or clients

This is due to OS X's Internet accounts system, which manages accounts for things like calendars, contacts, reminders and notes.

It includes the processes accountsd (part of Accounts.framework), com.apple.AddressBook.InternetAccountsBridge and com.apple.AddressBook.ContactsAccountsService (part of AddressBook.framework) and others.

It's failing to talk to the mDNSResponder process, which handles Bonjour and dynamic DNS lookup. I don't know precisely why it would try to use mDNSResponder, but it's clear that someone at Apple screwed up when they configured the sandbox permissions.

In my case, the problem went away after I disabled and then re-enabled my Fruux account, under System Preferences -> Internet Accounts. I use Fruux (a third-party CardDAV provider) for contacts and reminders.

Flipping this bit seems to have cleared up whatever was stuck in the accounts system.

Disable all accounts. (This includes checkboxes next to things like "Calendar" and "Reminders" within the account settings.) Wait a few seconds. You should see the "connect() failed" messages no longer appearing in the log after this. Then re-enable.

I have the same problem on my retina MBP mid-2012. Connecting to mac mini address book server. Fails precisely with the same problem and log entry. The com.apple.AddressBook.InternetAccountsBridge does not seem to be able to connect to mDNSresponder when trying to resolve the server hostname which I entered into the InternetAccountSettings PrefPane. I spent the whole day debugging the stupid problem, giving up now.

Last thing I did was attaching lldb to com.apple.AddressBook.InternetAccountsBridge process and setting some breakpoints in _connect_nocancel, doing stack backtraces and function parameter dumps to verify what running truss on the process suggested before:

proc_info(0x8, 0x2FC, 0x2) = 0 0

socket(0x1, 0x1, 0x0) = 4 0

setsockopt(0x4, 0xFFFF, 0x1022) = 0 0

setsockopt(0x4, 0xFFFF, 0x1100) = 0 0

connect_nocancel(0x4, 0x7000001166F0, 0x6A) = -1 Err#1

__semwait_signal_nocancel(0xF07, 0x0, 0x1) = -1 Err#60

connect_nocancel(0x4, 0x7000001166F0, 0x6A) = -1 Err#1

__semwait_signal_nocancel(0xF07, 0x0, 0x1) = -1 Err#60

connect_nocancel(0x4, 0x7000001166F0, 0x6A) = -1 Err#1

__semwait_signal_nocancel(0xF07, 0x0, 0x1) = -1 Err#60

connect_nocancel(0x4, 0x7000001166F0, 0x6A) = -1 Err#1

close_nocancel(0x4) = 0 0

<<<< repeating a couple of times during spinning beachball session >>>>

So everything appears as if the com.apple.AddressBook.InternetAccountBridge process spawned from the AddressBook.framework via launchd lacks the necessary sandbox privileges to talk to mDNSresponder. Unfortunately I cannot seem to find the correct sandbox configuration .sb file that applies here. Maybe someone else can. Anybody here running a WD MyBook external HDD by the way? Probably not related, but the system complained some time before that the drive manager software was not supported on El Capitan and I have the vague feeling that things started to go south from there.

Apple, bugs like this one are acceptable in beta software and developer prerelease, not in .2 service releases. When I take a look at the system log it is full of error messages like the ones from this problem. Who knows what else is broken and which ones can safely be ignored. A snow-leopard-like cleanup exercise would be highly needed for OS X right now. I don't need new UI skins, GUI elements or Facebook integration, what I need is a reliable operating system I can work with.

Frustrated,

--j

I only had this issue after I did a completely clean install of 10.11.2 last night. (I had to do a clean install for some other reason)

I was very frustrated too and finally I restored these 2 folders from my old backup:

~/Library/Accounts

~/Library/Application Support/AddressBook

Now the issue is gone. So it looks like it is a bug in one of the latter OS version when saving these settings.

Hi Okrisz,

thank you for your reply. I haven't had time to try to debug this yet. However, I just applied the latest update, now running 10.11.3 and the behavior of the Contacts App improved a lot. I still see the spinning wheel a lot, but not as long and as often as before. The error log messages also disappeared.

Seems Apple fixed the issue. Very nice. Thank you!

--j

No changes on my side after applying the 10.11.3 update.