Roon crashing with OOM error on Linux 6.8.0-124-generic (ref#QR6EUR) [Partially Improved with Roon 2.70]

Hi! What’s not quite right with Roon?

· None of the above quite fits

None of the above quite fits

· None of these quite match

Tell us what's going on

· Roon crashes with OOM error.

Jun 09 23:46:04 macbook-ubuntu systemd[1]: roonserver.service: A process of this unit has been killed by the OOM killer.
Jun 09 23:46:04 macbook-ubuntu systemd[1]: roonserver.service: Failed to kill control group /system.slice/roonserver.service, ignoring: Invalid argument
Jun 09 23:46:04 macbook-ubuntu systemd[1]: roonserver.service: Failed with result 'oom-kill'.
Jun 09 23:46:04 macbook-ubuntu systemd[1]: roonserver.service: Consumed 4h 33min 28.703s CPU time, 13.7G memory peak, 742.6M memory swap peak.

> uname -a
Linux macbook-ubuntu 6.8.0-124-generic #124-Ubuntu SMP PREEMPT_DYNAMIC Tue May 26 13:00:45 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux

Tell us about your home network

· Eero mesh network - mix of 6E and 6+. The RoonServer host is connected via ethernet to one of the 6E devices.

How much memory does the Mac have, what is the size library of your library (tracks), and how large is the database folder?

The Out-of-Memory Killer basically means you ran out of physical memory, which probably means the device has insufficient physical memory.

The Mac has 16GB of memory and has been running without issue for years. I’ve not added more files to the database in a month or so. Roon starts and runs for a couple of hours without issue but with growing memory usage (starting about 15GB and rising to over 32GB before being killed) - hence my statement about the memory leak.

I have about 2252 local tracks on my Mac according to Roon.

du -hs /var/roon/RoonServer/Database/
1.4G /var/roon/RoonServer/Database/

Apologies - it starts at 2.6GB when I’m first able to play music. The virtual memory is 32GB and it’s killed when reaching 13GB

I see that RoonAppliance is the source of the growth and it’s continually creating threads, and killing a proportion.

steve@macbook-ubuntu:~$ ls /proc/2288712/task/* | wc -l
4419
steve@macbook-ubuntu:~$ ps -o thcount 2288712
THCNT
154

Total tracks is 22652 sorry, 2252 are local. This is well below the 100,000 that 8GB is recommended as minimum for.

Hi @Steve_Bannister,

Thank you for your post. The memory pressure is definitely not coming from library indexing, and even a less-resourced machine shouldn’t struggle with a library that size.

We’ve pulled logs and see the rising resource demand and GC load, and at the same time, Roon is attempting to complete verification across the network interfaces and never completes. How many network interfaces do you have on this Ubuntu-on-Mac?

We’ll escalate this to engineering. Please stand by.

I’ll leave this o Roon technical support, but it would be useful if you described your MacBook and Ubuntu, e.g., Intel/Silicon etc.

You hadn’t mentioned a memory leak, but I doub’t the latest build would runaway like this for a modest library. That’s certainly not my experience, and I’ve been monitor memory usage for some time.

Thanks - I have a single physical network interface. Wifi is disabled.

There are docker networks on the systemand it’s running a netbird(wireguard-based) instance which provides a second IP address but that shouldn’t interfere with Roon.

$ neofetch
.-/+oossssoo+/-.               steve@macbook-ubuntu
`:+ssssssssssssssssss+:`           --------------------
-+ssssssssssssssssssyyssss±         OS: Ubuntu 24.04.4 LTS x86_64
.ossssssssssssssssssdMMMNysssso.       Host: MacBookPro13,3 1.0

/ssssssssssshdmmNNmmyNMMMMhssssss/      Kernel: 6.8.0-124-generic
+ssssssssshmydMMMMMMMNddddyssssssss+     Uptime: 2 days, 21 hours, 55 mins
/sssssssshNMMMyhhyyyyhmNMMMNhssssssss/    Packages: 1856 (dpkg), 7 (snap)
.ssssssssdMMMNhsssssssssshNMMMdssssssss.   Shell: bash 5.2.21
+sssshhhyNMMNyssssssssssssyNMMMysssssss+   Resolution: 2880x1800
ossyNMMMNyMMhsssssssssssssshmmmhssssssso   Terminal: /dev/pts/0
ossyNMMMNyMMhsssssssssssssshmmmhssssssso   CPU: Intel i7-6920HQ (8) @ 3.800GHz
+sssshhhyNMMNyssssssssssssyNMMMysssssss+   GPU: AMD ATI Radeon RX 460/560D / Pro 450/455/460/555/555X/560/560X
.ssssssssdMMMNhsssssssssshNMMMdssssssss.   Memory: 12909MiB / 15888MiB
/sssssssshNMMMyhhyyyyhdNMMMNhssssssss/
+sssssssssdmydMMMMMMMMddddyssssssss+
/ssssssssssshdmNNNNmyNMMMMhssssss/
.ossssssssssssssssssdMMMNysssso.
-+sssssssssssssssssyyyssss±
:+ssssssssssssssssss+:
.-/+oossssoo+/-.

OK - I spotted RoonArc continually failing to find a route out over uPNP with the Eero router (odd as it was previously working) and I thought it might not be not cleaning up properly. I’ve just added a manual port out on my router but I still see similar memory growth…

Any thoughts on this issue?

Roon technical support will reply after they have had a response from engineering.

Hey @Steve_Bannister,

Thanks for your patience so far! We have a potential optimization recently inlucded in our latest version of Early Access. If you’re interested in testing to see if this update helps you with your performance issues, I’ll share the process on how to migrate to EA below:

If not, we have some additional diagnostic logging we can enable on your server that could provide further insight for our development team.

Let us know your thoughts, thank you :folded_hands:

Thanks for getting back to me. I’ve installed the early access release and will monitor the memory usage. Happy for you to enable any diagnostics that you want.

Hi @Steve_Bannister
Thanks for the update. From the diagnostic data we can see that the memory usage has indeed decreased from 14GB to 4GB after installing EA. Please monitor the behavior and let us know if you see any spikes or increases.

Hi, I’ve been away for a few days but the server is still running. The memory has increased to 6.4GB but I don’t know what is usual now :slight_smile:

Up at 8.4GB today.

Hi @Steve_Bannister,

Be sure to migrate the GUI (Roon Remotes) to the Early Access track, too; a build track mismatch can cause connectivity issues.

Our QA and development teams are carefully monitoring the #earlyaccess section for feedback, so we can merge your most recent posts into a topic thread in that category if you would prefer.

Hi @Steve_Bannister,

The team has a ticket tracking this behavior. We’ll share information here as it becomes available and the ticket proceeds through the pipeline.

Thank you again.

Hi @Steve_Bannister,

We wanted to check in to see how things were performing for you in the last week. Diagnostics indicate that you migrated your devices to the EA testing branch where we’ve included some memory and performance improvements.

Are you still experiencing this crashing? The ticket is in our pipeline but we want to confirm if the nature of the symptom has changed before development proceeds with this one. Thank you!