Sudden 100% CPU Usage Due to Possible Roon Deadlock (ref#VGQ3F1)

Support
1

What app are you having the slowness issue with?

· Roon

What kind of performance/speed issue are you experiencing?

· The app is using a lot of resources (CPU/RAM)

Please try to reboot your Roon Server

· Yes, rebooting helps, but the issue returns after some time

Please try to reboot your networking gear (Router/Switches/etc.)

· No, the issue is still the same even after a reboot

Is there any change in behavior if you try to navigate to Roon Settings -> Library and set both Background and On-Demand Audio Analysis to Throttled or Off?

· No, the issue is still the same

Does the issue happen on multiple Roon Remotes (controllers) or just one?

· Issue happens on multiple remotes

Router Domain Name System (DNS) change

· I was able to change my router's DNS servers but it did not help

What is the operating system of your Roon Server host machine?

· Linux Server (Ubuntu, Fedora, ArchLinux...)

Timestamp of issue occurrences

· 21-09-2026 08:12AM local time Amsterdam

Describe the issue

Cpu suddenly consumes 100% and stays there until reboot. supposedly the 'Broker' and 'Remoting' thread in a deadlock.
I've been monitoring cpu in Grafana the last day. I only have these figures of the last day.

Describe your network setup

Unifi network (USG Ultra + switch) with ad blocking enabled

2

When I tried to restart this morning, the issue persisted. Reverting back to production version instead of early access to see if the issue disappears.

4

Hi @Paul_van_den_Berg,

Thanks for writing in, and for the Grafana captures. After reviewing a fresh set of Roon Server logs, we were able to see the following:

It’s not a deadlock. It’s a runaway loop in the Live Radio channel query, roughly 984,000 iterations in a few hours, about 15,000 per second. That’s the flat 100% plateau on your chart.

The trigger is your Mac at 192.168.y.161. Its connection keeps dropping, and each time it returns it can’t resume its session:

08:11:25 [initconn 192.168.0.161:64500] Initialized Session because we couldn't resume
08:11:32 [radio/query] performing channel query ← loop begins

From there it feeds itself: the loop starves the broker, your remote times out, reconnects, fails to resume, re-subscribes. The memory climb is the same loop, four accessor threads stall and never tear down, pinning ~2.5 GB.

Your downgrade confirmed it. On 2.71 that Mac still drops and reconnects just as often, but the loop never starts:

So the ad-blocking, DNS, and audio analysis settings are all ruled out. Please stay on production for now, we’re taking this to the team.

Two things would help us narrow it down: which remote were you using on that Mac, and was it asleep or backgrounded when this started? Its network link also looks unstable in the logs, Wi-Fi or wired? Not the cause, but it’s what keeps pulling the trigger.

5

Remote on the Mac is version 2.71 (build 1683) production. I have auto update enabled so not entirely sure it was updated in the meantime.

I think this is when the device was awake as it was around the start of my working day.

6

Hi @Paul_van_den_Berg,

Thanks again for the flag. We’ve escalated this report and will respond with new information as it becomes available, along with next steps.