Skip to main content

Bird is causing high CPU on my macOS

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:

trustd is 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() or SecKeyVerifySignature(), those calls often route to trustd over 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.

ecosystemanalyticsd contains a component called RosettaCoordinator — 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 SecTrustEvaluateIfNecessarySecKeyVerifySignature → 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

Popular posts from this blog

I'm not a passionate developer

A family friend of mine is an airlane pilot. A dream job for most, right? As a child, I certainly thought so. Now that I can have grown-up talks with him, I have discovered a more accurate description of his profession. He says that the truth about the job is that it is boring. To me, that is not that surprising. Airplanes are cool and all, but when you are in the middle of the Atlantic sitting next to the colleague you have been talking to past five years, how stimulating can that be? When he says the job is boring, it is not a bad kind of boring. It is a very specific boring. The "boring" you would want as a passenger. Uneventful.  Yet, he loves his job. According to him, an experienced pilot is most pleased when each and every tiny thing in the flight plan - goes according to plan. Passengers in the cabin of an expert pilot sit in the comfort of not even noticing who is flying. As someone employed in a field where being boring is not exactly in high demand, this sounds pro...

"You are a friendly breadwinner"

A recent blog post by Pete Koomen about how we still lack truly "AI-native" software got me thinking about the kinds of applications I’d like to see. As the blog post says, AI should handle the boring stuff and leave the interesting parts for me. I listed down a few tasks I've dealt with recently and wrote some system prompts for potential agentic AIs: Check that the GDPR subprocessor list is up to date. Also, ensure we have a signed data processing agreement in place with the necessary vendors. Write a summary of what you did and highlight any oddities or potentially outdated vendors. Review our product’s public-facing API. Ensure the domain objects are named consistently. Here's a link to our documentation describing the domain. Conduct a SOC 2 audit of our system and write a report with your findings. Send the report to Slack. Once you get approval, start implementing the necessary changes. These could include HR-related updates, changes to cloud infras...

PydanticAI + evals + LiteLLM pipeline

I gave a tech talk at a Python meetup titled "Overengineering an LLM pipeline". It's based on my experiences of building production-grade stuff with LLMs I'm not sure how overengineered it actually turned out. Experimental would be a better term as it is using PydanticAI graphs library, which is in its very early stages as of writing this, although arguably already better than some of the pipeline libraries. Anyway, here is a link to it. It is a CLI poker app where you play one hand against an LLM. The LLM (theoretically) gets better with a self-correcting mechanism based on the evaluation score from another LLM. It uses the annotated past games as an additional context to potentially improve its decision-making. https://github.com/juho-y/archipylago-poker