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.
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/
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.
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…
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.
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.
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.
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!