There is no lack of people complaining about MacOS Tahoe, mostly about rounded corners and inconsistent design decisions.
I have not paid that much attentention to that, but there is one mac bug i have paid attention to. It hasn't been a visual or ux but rather few system processes pegging the CPU.
trustd, alongside with ecosystemd and ecosystemanalyticsd all reported high CPU usage. I can't
exactly recall when this started, it might have predated my Tahoe upgrade but anyway, the trio of processes all had high CPU usage.
Sure, it may have been the virtual efficiency cores and whether it affeced battery life or slowed down other processes i don't know to be honest. But anyway, I wanted to figure out what was going on.
Here is a snippet showing the CPU usage (3rd col)
$ ps aux | grep -E "trustd|ecosystem" _trustd 399 68.4 0.1 ... /usr/libexec/trustd root 421 54.1 0.0 ... ecosystemd root 423 57.8 0.0 ... ecosystemanalyticsd
So what are these processes?
Sorry, have to include a direct LLM response here. Claude says:
trustdis macOS's trust evaluation daemon. It handles certificate verification, code signing checks, and cryptographic trust operations on behalf of the rest of the system via XPC. It's a system-domain daemon, meaning it runs as root under the system launchd instance — not inside any user session.When something calls
SecTrustEvaluateIfNecessary()orSecKeyVerifySignature(), those calls often route totrustdover XPC. Under normal conditions trustd is nearly idle. When it's at 60% CPU, something is hammering it with verification requests — thousands per second on a single thread.Ecosystemd and ecosystemanalyticsd are Apple's Ecosystem framework daemons, introduced to support iPhone Mirroring and Handoff features in macOS Sequoia. They as root in the system launchd domain.
ecosystemanalyticsdcontains a component calledRosettaCoordinator— despite the name, this isn't just about Rosetta 2. It scans running processes to build an inventory for Apple's ecosystem telemetry. For each binary it finds, it:1. Inspects the binary's code signature
2. Tries to locate the app's iCloud document root via
com.apple.bird(the iCloud Drive sync daemon)3. Records usage metadata
So some system processes, doing some very important work I'm sure.
There are dozens of articles / blogs / forum posts dating few years back about high trustd CPU usage. None of the fixes recommended there (I tried them all) helped. I had to jump into browsing the macos system logs with the logs command and see if there was something weird. Of course, I used Claude here to analyze the logs.
In no time, Claude found out that there is this thing called com.apple.bird that was a likely culprit.
Bird is the iCloud Drive sync daemon which simply syncs files between the mac and iCloud.
ecosystemd, like trustd, is a system process. bird on the other hand lives in your user
session.
According to Claude's findings from system logs ecosystemd constantly tries to talk to bird over XPC (macOS IPC
mechanism), but bird isn't visible from the system domain. Every lookup fails with:
XPC error 159: failed to do a bootstrap look-up
There should be some kind of a exponential backoff mechanism here but no such luck. It retries immediately, forever. Each retry triggers
SecTrustEvaluateIfNecessary → SecKeyVerifySignature → a call to trustd to verify a code signature.
trustd handles these serially on a single thread, so it gets buried.
The trio of processes is stuck in a loop.
Killing the processes doesn't help as launchd restarts them almost immediately with no throttle. You could just out right disable the services but seems a bit overkill.
The annoying part is that signing out of iCloud / disabling iCloud Drive doesn't stop the loop immediately. The XPC lookup fails before iCloud is even involved, so the CPU cycles stay high until you actually reboot.
The fix that ultimately ended up working was rebooting. Signing out of iCloud and back in beforehand seemed to help bird come up cleanly on the next boot, but the reboot was the key part.
I was happy for a while until the problems started reoccuring after a few days. Trustd, was yet again showing up as a high CPU consumer.
It seems that there is some sort of a race condition on boot between the iCloud Drive sync daemon and the ecosystemd process. The ecosystemd starts up before the user space bird process is ready which seems to trigger the loop. Normally bird wins the race and registers its XPC endpoint before ecosystemd comes knocking, but when it doesn't the stale auth to iCloud triggers the loop. Or so I assume.
Here are some commands you can use to diagnose the problem:
log show --predicate 'process == "ecosystemd"' --last 5m --info
log show --predicate 'process == "bird"' --last 10m --info | grep -iE "error|BRCloud"
launchctl print system/com.apple.trustd | grep runs
In the ecosystemd output, look for lines like:
failed to do a bootstrap look-up: xpc_error=[159: Unknown error: 159] Error querying cloud docs root URL: No such file or directory
I'm pretty sure this is a bug in my specific setup since I would imagine not all macos users are affected by this.
Comments
Post a Comment