Macbook Pro got slow after upgrade to 10.9.5 (Mavericks)

Isenberg, no I haven't activated or checked the opendirectoryd log as yet. Need to physically go the the customer location so I can disconnect the network cable when the system "locks up". Will hopefully get a chance to do that next week, customer is isolated from the problem at the moment so all good. Will report back if I find anything.

We experience this same problem on any mac joined to our Active Directory domain that was upgraded to 10.9.5 . We were able to track it down to millions of connections per machine being made to the domain controllers Global Catalog port 3268.

FIXED:

We were able to fix this problem by removing the AD Domain from the Search Policy -> Contacts in the Directory Utility . After this the extra connections stopped and users could login in using their AD credentials again,

Found the same thing here. On my test machine, I noticed it caused a problem when I bound with the ALL DOMAINS switch set to 'disable.'

To unbind from the command line using SSH or ARD's UNIX command, it looks like you can use this (as root or with sudo):

shortDomainName="yourdomainnamegoeshere"

rm -rfdv /Library/Preferences/DirectoryService

rm -rfdv /Library/Preferences/OpenDirectory

rm -rfdv /var/db/dslocal/nodes/Default/config

dscl /Search -delete / CSPSearchPath "/Active Directory/$shortDomainName"

dscl /Search/Contacts -delete / CSPSearchPath "/Active Directory/$shortDomainName"

dscl /Search -delete / CSPSearchPath "/Active Directory/$shortDomainName/All Domains"

dscl /Search/Contacts -delete / CSPSearchPath "/Active Directory/$shortDomainName/All Domains"

killall opendirectoryd

For the shortDomainName variable, enter the short form of your AD domain name. For example, if your domain name is acme.com, use ACME.

I can confirm that the Search Policy settings (Authentication in my case) under the Directory Utility was the culprit. I did the SMC, PRAM, unbind and rebind, remove from Apple MDM and nothing fixed it until I went into Search Policy (Paths) and removed everything except Active Directory/DOMAIN/All Domains. After that change the issue was resolved and the user experienced normal CPU usage again.

I saw symptoms exactly as GregD7 describes. I also followed the same steps to disjoin, clean the .plist file, and rejoin to my AD. Symptoms re-appeared immediately after re-join was complete. I then also observed quite a bit of traffic from opendirectoryd & NetBIOS processes directed at one of my DC's. Looking through all the directory settings, I found what seemed to be an extra Directory Domain entry on the Directory Utility > Search Policy > Authentication listing. The affected machine had 3 entries:

1. /Local/Default
2. /Active Directory/MYDOMAIN
3. /Active Directory/MYDOMAIN/All Domains

No other Mac I examined had the 2nd entry present. I removed this entry from the affected machine and rebooted. The issue has seemingly disappeared after that point. Hope that helps other suffering from this issue.

FYI all the issue appears to have been resolved by Apple, not sure if I missed a communication, or if they haven't gotten around to closing out tickets submitted to AppleCare for this.

Below is how I discovered it was no longer a problem:

I was testing today with ARD's ability to update software on Macs in the environment today and I sent a unix command to two machines with 10.9.4 "softwareupdate -i -a" to install all available updates.

After restarting the machines they updated to 10.9.5, and I no longer see the previous issue. There is no erroneous search policy anymore, and the OpenDirectory tool is no longer spiking. No need to turn off wireless or unplug the network cable to be able to login anymore to be able to delete the search policy, everything is working fine on both macs.

Hi all,

just to confirm that i upgraded today and issue is STILL there but, fortunately, solved it deleting search policy. 😎

thanks to all of you for the tips and support!!

andy

Hello All - We also experienced this after 2 Mac Book Pros were upgraded to 10.9.5. These machines were bound to the network in AD. One machine we reverted back to 10.9.4 by way of Time Machine. The only time opendirectoryd would go haywire was the machine being on our corporate network and having been upgraded to 10.9.5.

The other was unbound from the network. Is there a ways to alert Apple to this bug?

bugreport.apple.com

I filed a bug with the symptoms I was seeing on my machine, I have not had the time to re-upgrade to 10.9.5 on my domain mac to test if the search policy fix (removal of the extra search domain) fixes the issues with opendirectoryd.

This solved my problem! I was having the same problem as everyone getting about 350% CPU consumption from OpenDirectoryD. Removing all EXCEPT for /Active Directory/XYZ/All Domains solved this! Now it doesn't go beyond 5% and my computer is back to full speed.

Thanks Keith.

Thanks for the resolution. I removed the /Active Directory/MYDOMAIN entry and now my machine is usable again!

Much appreciated.

Tom

This may be slightly off-topic, but I believe still relevant to the folks here: Has anyone who has had trouble with this update upgraded to Yosemite? If so, did you have issues with AD? I'm a bit leery about it after my previous experience with 10.9.5.

I am using a 2011 iMac, the plan is for me to update after 1 month in case there are other SMB / AD issues in the current .0 release of Yosemite.

On my home 2013 iMac, I updated and the short few hours I worked on it, everything seemed fine, (iPhoto, iMovie... etc).

Keith is quite correct.

See Apple KB Article: OS X: If the opendirectoryd process CPU utilization is high after updating to OS X v10.9.5

Make sure you remove from Authentication and Contacts, this is vital otherwise you will still have high CPU %.

I ran into a similar issue this week with regards to OS X 10.9.5 (with all updates) AND 10.10 pinwheeling on login; sometimes for as long as 20 minutes. We have a number of Macs configured to log in with Active Directory, but the problem seemed to occur even when a local account was being accessed. However, logging in via safe mode worked completely fine. After a few days of troubleshooting, we discovered that the LogMeIn menu bar application was freezing during the login process. While it was unresponsive, the network connection was dropping packets and disconnected a dozen times (we monitored from the Cisco switch). The only way we found this connection was I got lucky that I forgot to quit out of Activity Monitor when I rebooted. Activity Monitor started up at boot just before the machine locked up. I could see the unresponsive process as it pinwheeled, but couldn't force it closed. I uninstalled LogMeIn from all the affected machines, and now they have all come back to life. I'm not sure if this applies to everyone, but I thought I'd share as we were going insane trying to figure out what was going on. Hopefully patches will come out that will fix the issue.