[morpheus76]

Since upgrading to Lion I see a reoccurring issue whereby opendirectoryd will spin chewing up all my CPU. The image below shows the CPU spiking with automountd and opendirectoryd. When this is happening, I've noticed that it appears some applications become unresponsive when attempting to write to the file system, most noticeably is when developing in Eclipse.



Any suggestions on how to avoid this problem would be hugely appreciated. I do not see any red flags in system logs nor in /var/log/opendirectoryd.log

Thanks much.

[Waragainstsleep]

Are you attached to an OD?

[morpheus76]

That's the odd part, no. I do have a Time Capsule, but this is happening running on my home network. In addition to my MacBook Pro this is happening on, I do have an iMac also running Lion on the network, though no issues that I've observed on that one (though granted it's the "family" system and I do not touch it that often).

Cable Modem -> Time Capsule -> 802.11n Wireless -> Laptop running Lion

Nothing fancy installed. Normal standard tools like iStat Menus installed, etc. though I did just notice that I have an old Menu Meters installed that I didn't upgrade that I'll uninstall now.

Thanks for the quick response!

[Waragainstsleep]

Fire up Console and check your logs for (very frequently) repeated messages. Probably involving launchd. It is most likely an app that hasn't been properly updated yet.

[morpheus76]

Regarding launchd, I did indeed run into this problem with one app that I fixed last week. Some Video Accelerator that I barely recalled installing -- that has been removed and I stopped getting the lovely "trying again in 10 seconds". The only other messages I see repeat periodically were similar to the following.

I switched my Eclipse over to be Cocoa based instead of Carbon to see if this now fixes my issues. I've only just made the change so will take a few before I have an answer. Apart from these messages, there is nothing in my Console that appears very frequently and the opendirectoryd speedup seems to be much more frequent than the messages below.

Thanks again!

Jul 29 13:16:40 Macintosh eclipse[321]: kCGErrorInvalidConnection: CGSGetWindowTags: Invalid connection
Jul 29 13:17:54 Macintosh eclipse[321]: kCGErrorInvalidConnection: CGSGetWindowTags: Invalid connection
Jul 29 13:19:16 Macintosh java[3209]: dlopen(<snip>/plugins/org.eclipse.equinox.launcher.carbon.macosx_1.1.100 .v20110502/eclipse_1406.so, 1): no suitable image found. Did find:
<snip>/plugins/org.eclipse.equinox.launcher.carbon.macosx_1.1.100 .v20110502/eclipse_1406.so: no matching architecture in universal wrapper
Jul 29 13:19:23 Macintosh java[3210]: CPSSetForegroundOperationState(): This call is deprecated and should not be called anymore.
Jul 29 13:19:54 Macintosh eclipse[321]: kCGErrorInvalidConnection: CGSGetWindowTags: Invalid connection
Jul 29 13:26:07 Macintosh java[4677]: CPSSetForegroundOperationState(): This call is deprecated and should not be called anymore.

[morpheus76]

Bummer, just as I finished posting this message, sure enough, the same opendirectoryd / automountd spinng CPU triggered again.

[morpheus76]

To confirm, when the CPU pegs, there are no messages within a couple minutes in the Console.

I've read somewhere about turning up logging on opendirectoryd but I've had little luck making sense of it. Is there perhaps some extra logging I could turn on somewhere to get more information in my opendirectoryd.log file?

Cheers.

[morpheus76]

OK, a bit more data...

I've turned on opendirectoryd debugging and I see it doing a huge number of ODQueryCreateWithNode

cat opendirectoryd.log | grep ODQueryCreateWithNode | wc -l
4446

This is 4,446 during one of the CPU pegging incidents. I'm not sure what ODQueryCreateWithNode is, but I see it doing repetitively ones like the following:

011-07-29 15:26:50.022 CDT - 25916.512071 - ODQueryCreateWithNode request, NodeID: 538667E6-2E44-42E4-B4F4-E7C0B6C63699, RecordType(s): dsRecTypeStandard:Users, Attribute: dsAttrTypeStandard:RecordName, MatchType: EqualTo, Equality: CaseIgnore, Value(s): src.zip, Requested Attributes: dsAttrTypeStandard:RecordType,dsAttrTypeStandard:R ecordName,dsAttrTypeStandard:HomeDirectory,dsAttrT ypeStandard:NFSHomeDirectory,dsAttrTypeStandard:Ap pleMetaRecordName,dsAttrTypeStandard:AppleMetaNode Location, Max Results: 2147483647
2

This is repeated for src.jar, src.zip, and *.

My guess is something is going on between Java (not included by default now in Lion) and opendirectoryd -- though I don't know what. Clearly this can't be just a catastrophic break with Java so something else is causing opendirectoryd and Java to misbehave. I'm going through my Java settings in Eclipse too to see if there is anything else that may cause this.

[morpheus76]

Using odutil, I can see a bunch of search requests:

Macintoshesktop $ odutil show all
Active connections:

Node Refs Module Destination Socket Connected Shared Active Requests Credentials Timeout
-------------- ---- --------- ----------- ------ --------- ------ --------------- ----------- -------
/Local/Default 29 PlistFile X X 0 0
/Search 2 search X 0 0
/Search 2 search X 0 0
</Search repeated 20 more times>

Going through the Directory Utility, I can't see any specific directory information enabled.

[Waragainstsleep]

Its definitely something to do with Java. I haven't delved into the guts of Lion much yet, but from flicking through the odd page here or there it looks like opendirectoryd might have taken over some duties from launchd since Snow Leopard. Which would at least explain the link.

[morpheus76]

On a whim I re-installed the Java Developer Documentation for 10.7 and I have not noticed any lockups since that change. So to recap, I'd summarize this as:

OS X Lion 10.7
with Java installed
without Java Developer Documentation

Eclipse > File Write actions often caused excessive ODQueryCreateWithNode operations causing spinning of opendirectoryd and automountd

Installing the Java Developer Documentation

Eclipse > File Write actions function correctly without lockup.

My guess is that something happens in the Java VM implementation on file writes that can potentially trigger a search for src.jar/src.zip, that when the Java Developer Documentation is not installed, fails / retries attempting to find the resource.

Certainly I may be completely off base, but that's the best I can do with the data available.

Thanks Waragainstsleep for your assistance. From my standpoint, at least I can work reliably again.

[Waragainstsleep]

You're welcome. For all the good I did.