RoonServer memory leak causing crashes on Ubuntu 24.04 (ref#FPTTNW)

Support
1

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

· Titel: RoonServer memory leak — RAM grows to ~15GB within an hour, recurs after both storage-location reset and full database reset

Text:

I'm running into a recurring memory leak in RoonAppliance on Linux (Ubuntu 24.04, RoonServer). Managed heap grows continuously until the process crashes.

Symptoms:
- RoonAppliance process RSS grows linearly, roughly 300+ MB/min
- Log shows Managed-live pinned at 99% of committed, growing steadily (not the normal fluctuating pattern from GC)
- Crashes within 40–50 minutes of startup once RSS reaches ~14–15 GB
- Healthy baseline for this library is normally ~1–2 GB RSS with Managed-live fluctuating 50–80%

History (this keeps recurring):
1. 2026-07-17 — first occurrence, tracked down to orphaned index entries referencing backup files that Roon had once indexed under my music storage location (before an fstab mount change). Fix: remove and re-add the storage location in Settings → Storage. This resolved it — RSS dropped from ~15GB to ~200MB immediately.
2. 2026-07-28 — leak returned after 11 stable days. This time the storage-location reset alone wasn't enough to restore trust in the DB, so I did a full database reset (stopped roonserver, moved Database/SearchIndex folders aside, restarted, re-added storage location, full rescan of ~5,700 tracks).
3. 2026-07-31 — leak returned again after only 3 days, and faster this time (reached 15GB in under 50 minutes vs. ~40+ minutes before).

So a full database reset did not durably fix it, and the recurrence interval is getting shorter, not longer. My working theory is that something in the storage/index layer keeps regenerating references to files that no longer exist (possibly related to filesystem snapshot/backup rotation on my end, though the music folder itself is verified clean via ls/find/mount), but I haven't been able to pin down the actual mechanism from the client side.

Setup:
- RoonServer on Ubuntu 24.04.3, headless Linux
- Library: ~5,700 tracks, local storage only (no NAS-mounted library folder)
- Diagnostics/logs available on request

Has anyone seen this pattern before, or can Roon support pull a diagnostic upload to investigate what's generating these leaked references? Happy to send logs or a diagnostics bundle.

Tell us about your home network

· fritzbox

2

Hello @Tilmann_Kruse ,

Thank you for the report. Can you please these instructions to save and upload your database to the link below, and let us know once uploaded? We’ll escalate your case to the team for review.

https://workdrive.zohoexternal.com/collection/nocvrfc5b2ddab55140af8640f1d7ce13291e/external

3

Uploaded the database archive to the WorkDrive link — thanks for the quick reply.

File: roonserver-db-2026-07-31.tar.gz (~107 MB), containing the current Database, SearchIndex, and Settings folders from /var/roon/RoonServer/ on my Ubuntu 24.04 RoonServer install, captured right after stopping the service (so it reflects the state that was actively leaking, not a stale snapshot).

For reference, this is now the third occurrence of the same leak pattern:

  • 2026-07-17: fixed via storage-location remove/re-add (held 11 days)
  • 2026-07-28: storage-location reset alone wasn’t enough, did a full database reset (held only 3 days)
  • 2026-07-31: leak returned again, faster this time (~15GB RSS within 50 minutes of startup vs. ~40+ minutes previously)

Let me know if you need anything else — logs, a fresh diagnostic upload, or another database snapshot after I bring the server back up.

Ref: #FPTTNW

4

Hello @Tilmann_Kruse

We looked through your diagnostic data logs and found what’s driving the memory growth. Your Roon storage location is set to the root of the mount (/mnt/roon), and that same folder also contains a sicherungen/timeshift-roon/snapshots-daily/… tree, which looks like a daily Timeshift backup of this server itself. Roon’s importer is scanning through those backup snapshots and treating the image files inside them as candidate cover art, and since a new full snapshot gets added every day, that workload only grows over time. That’s what’s driving memory up to the 14 to 15 GB range each session before a restart.

Could you please exclude that backup folder from Roon’s scope? Either point your watched folder specifically at your music subfolder rather than the mount root, or move the Timeshift snapshot target outside of /mnt/roon entirely. Whichever is easier on your end works.

Once that’s done, please do a single clean edit of the existing storage location’s path (rather than removing and re-adding it) so it can pick up the change and rescan without starting over from a new location. After that, keep an eye on memory usage over the next day or two and let us know if it stays stable.

5

Hi,
▎
▎ Thanks for looking into this — that was a very helpful lead. We tracked it down further and found the actual source, which is slightly different from what your diagnostic data suggested:
▎
▎ /mnt/roon (our storage location root) contained a folder RoonBackups/ with a roon_backup_root marker file (“ROON BACKUP ROOT v2”) and ~730 content-hashed files, totaling ~206 MB, all timestamped July 28 — not a Timeshift snapshot as we first assumed. This turned out to be from a one-off manual backup we triggered ourselves, where we accidentally selected /mnt/roon as the destination instead of our regular scheduled backup folder (/var/backups/roon) in the folder picker — an easy mix-up since both live in the same picker. Our scheduled daily backup has always been correctly pointed at /var/backups/roon and has been running fine throughout (confirmed via the app).
▎
▎ So the mechanism you identified — a backup-like directory tree inside the watched storage location being scanned as image candidates — was exactly right; we just had the wrong source. We’ve since verified /mnt/roon contains no other stray backup or snapshot trees. We’re removing the misplaced RoonBackups/ folder now and will do a clean rescan of the storage location afterward.
▎
▎ Thanks again for the fast and accurate diagnosis — we’ll monitor memory usage over the next few days and report back if anything looks off.
▎
▎ Best,
▎ Tilmann

6

Hey @Tilmann_Kruse,

Thanks for your patience while we dug into the logs and the database. We’ve got a clearer picture now, and it points somewhere different from where the thread had been heading.

First, on the storage/snapshot idea: we chased that one down and it didn’t pan out. There’s no filesystem or backup activity involved in the growth. Nothing in your logs references missing files, and when we ran a churn test with snapshot-shaped directories sitting inside the watched tree, it produced no growth at all. So we can set that theory aside.

What is actually happening is a retention issue tied to client connections. There are two separate causes behind it, and here’s where each one stands.

The one concrete step available to you right now is to update off 2.70. Both 2.71 and 2.72 contain the first fix, and it directly addresses one of the two causes of exactly the growth you’re describing. This doesn’t depend on anything unreleased, it’s shipping very soon, so I’d recommend moving up whenever it’s convenient.

I want to be straight with you about what that will and won’t do. On any build up to and including 2.72, memory will still climb in proportion to the number of client connections made since Roon Server last started, because the second cause is still present. The remaining fix for that one is written and currently in review, and it’ll land in a later release. So updating helps, but it won’t fully flatten the curve on its own yet.

In the meantime, restarting Roon Server fully resets it. That’s a real mitigation, not a placebo, the retention is per-connection-since-startup and does not survive a restart, so if you restart periodically you won’t accumulate.

A few things that increase your exposure between restarts: lots of remotes/apps connecting and disconnecting, and clients that drop abruptly, device sleep, an app being force-quit, a network drop, rather than closing cleanly. The fewer connect/disconnect cycles you go through between restarts, the less it builds up.

Last point, on the crashes themselves. We weren’t able to reproduce a crash or an out-of-memory condition on our end, and your logs don’t show one either, no OOM, no abnormal exit, and nothing above 2 GB RSS across 156,095 samples. So if you’re genuinely seeing the process die, that looks like a separate issue from the growth above, and the asks from earlier still stand. In particular, next time it happens could you grab:

journalctl -k | grep -i oom

and a capture taken before you restart. That would tell us a lot about whether the kernel is killing it or something else is going on.

Thanks again, let us know how the update goes and whether the restart cadence holds things steady for you.