The next version of Debian Linux called “Bookworm” is scheduled to be released in June. Does anyone have experience with Roon on this version yet? I’ve been running a test server for the OS by itself for a few weeks, and it seems really stable as Debian always is, but I know they’ve changed a lot of stuff. I’ll probably load Roon on there and experiment, but I’d sure like to avoid any problems/challenges others have already faced and solved!
I have been running a Debian Testing server for over the last few months, which is as close to Bookworm as you can get at this time. Compared to stable/Bullseye, quite a few changes all around – but nothing special to report regarding Roonserver.
2 Likes
Just curious–does Roon still have the “Metadata Improver Paused” bug under Bookworm?
2 Likes
Yes, it happens when the network goes away for a short time. Have to reboot the whole thing to get back to normal.
BTW, what’s the right way to stop/start RoonServer on bookworm?
sudo systemctl stop roonserver.service
does not seem to work on Bookworm
It appears that the bug persists. I use Cockpit to manage the server, so I just restart the Roon service, and all is well. I also wrote a quick & dirty shell script that does the same thing from the command line. Here’s the actual command:
systemctl restart roonserver
This is interesting.
@Steef_de_Bruijn recently updated the Roon Docker image many of us use to Bookworm (slim). I don’t think he was aware of this issue and I certainly wasn’t.
I tried the Bookworm image and saw a very significant increase in memory usage (about 4x). Did anyone else now running Bookworm see anything similar with a Docker or native deployment?
I run Linux on a Lenovo m910q computer, which has been reliable for years now. When I upgraded the machine to Bookworm, I didn’t notice any change in performance or memory usage. Since the machine is a dedicated Roon server, most of the memory remains free. If the OS is using more, I can’t tell. I’ve never seen the machine break a sweat.
This is interesting. Thanks. Here’s what I see.
Debian Slim, Bullseye:
- Container memory usage: 1.52GB
- Roon Appliance process memory usage: 1.25GB
Debian Slim, Bookworm:
- Container memory usage: 4.97GB
- Roon Appliance process memory usage: 4.72GB
Here’s what it looks like, graphed, to go from Bullseye → Bookworm → Bullseye:
This is a reasonably controlled test where the Roon bits are the same and only the OS image differs. These are the numbers I see after starting the container. Bullseye memory usage stays constant over time but Roon on Bookworm seems to consume more memory over time.
I can see why this wouldn’t matter on a dedicated machine. It actually doesn’t really matter in my environment because while I have a number of containers running on this machine, it’s nowhere close to being under memory pressure.
I don’t see an advantage to running Bookworm, though, especially given the metadata improver issue you described.
Memory usage on my machine has been stable. Running Roon on Bookworm, I see about 1GB used out of 16GB. With Bullseye, it was around the same. I’ve never seen any kind of spike. I do have a test server running in a Hyper-V virtual machine, and looks basically the same. I know almost nothing about how Docker works, but what you’re describing sounds . . . inefficient.
The only reason I’d propose for a Bookworm upgrade is to keep the system current and secure. I do like that it supports some proprietary drivers and firmware without me having to mess with the sources.list file or additional utilities. Big benefit? Not especially, but simple is good.
What you see on Bookworm is similar to what I see on Bullseye. I don’t understand what’s going on.
I’m with you on staying current - that’s why I suggested to @Steef_de_Bruijn that he upgrade in the first place 
I’ve been using his image for years but it’s easy enough for me to roll my own based on other distributions. I’m going to play with Ubuntu (probably JJ) just to see what happens.
Thanks for the chat.
Thank you for your advice, didn’t realize it was that simple and it works for me too. I come from the FreeBSD world and systemctl is new to me.
I see on bookworm a steady 1,3GB of mem usage on my test setup (docker-desktop op m1 macbook). Can’t explain the blowup on @gTunes setup.
I prepared an arch based image and running it now on my ‘production’ music server. Runs for an hour now using about 900MB of RAM without issues.
I am a bit hesitated to use arch as a base because of the rolling release nature of it. But it seems to work I can push the image to the hub under the ‘arch’ tag for remote testing if anyone is interested.
I spent some time earlier building containers based on different distributions, including Arch. The only distribution on which I see the significant increase is bookworm. Doesn’t matter if it’s slim or not.
Bullseye, Jammy Jellyfish, and Arch all use more RAM than you’re seeing, but it’s on the order of a couple hundred MB more, whereas Bookworm uses more than double.
Since this issue is unique to me, I don’t think you should change to Arch. I think I will, personally, though.
I’m doing my best to pretend that I know something about Linux (and Docker), but I really don’t. By trade, I’m a Windows and Mac guy.
I started with your Dockerfile and modified it as below for Arch based on what I saw elsewhere. Would you mind taking a look and letting me know how it compares to what you did? I’m using your run.sh unmodified and it seems to work fine.
Thanks for all the work you put into this - I wouldn’t have been able to get it going without it.
FROM archlinux:base
RUN pacman -Sy --noconfirm \
&& pacman -S --noconfirm openssh mc ffmpeg samba icu \
&& pacman -Scc --noconfirm
ENV ROON_SERVER_PKG RoonServer_linuxx64.tar.bz2
ENV ROON_SERVER_URL https://download.roonlabs.net/builds/${ROON_SERVER_PKG}
ENV ROON_DATAROOT /data
ENV ROON_ID_DIR /data
VOLUME [ "/app", "/data", "/music", "/backup" ]
ADD run.sh /
ENTRYPOINT /run.sh
Almost identical (don’t use --noconfirm with the pacman -Scc, it answers the default instead of the Y that you actually want):
FROM --platform=amd64 archlinux:base
LABEL org.opencontainers.image.authors="steef@debruijn.ws"
RUN pacman -Sy jack2 ffmpeg cifs-utils alsa-utils --noconfirm \
&& printf "y\ny" | pacman -Scc
ENV ROON_SERVER_PKG RoonServer_linuxx64.tar.bz2
ENV ROON_SERVER_URL https://download.roonlabs.net/builds/${ROON_SERVER_PKG}
ENV ROON_DATAROOT /data
ENV ROON_ID_DIR /data
VOLUME [ "/app", "/data", "/music", "/backup" ]
ADD run.sh /
ENTRYPOINT /run.sh
Ok, won’t change distros for now.
Steef
1 Like
This is very helpful. Thank you! There are a couple of tricks in yours I didn’t know were possible.
I’ll switch to the packages you’ve listed - they make more sense. I was probably looking at outdated references.
I’m going to continue to install icu in case it’s used for encoding scenarios. As far as I can tell, that’s the libicuxx equivalent.
Thanks again for your help!
icu is indeed necessary (but present in the base image)
1 Like
Thanks. I see that now. Hadn’t bothered to check but see now that it’s easy to dig around an image’s packages in the GUI.
This thread might interest you :
Thanks. I’m familiar with the memory leak issue including Roon’s assertion that it’s fixed in the latest release. I’ve seen the issue with some, but not all, Linux distros and runtime strategies.
The issue I’m describing here isn’t a memory leak - it’s a difference in the baseline memory consumption of the Roon process and, at least partially consequently, the Docker container itself. It’s not a function of growth over time, it’s the baseline as seen when the container is launched after giving it a few minutes to settle down.
When I get the Roon release that is currently rolling out, I’ll test Bookworm again just in case.
I just realized (for what it’s worth) that my Bookworm installation is command-line ONLY. I have no GUI stuff installed. That could make a difference. If I were searching for a memory leak, the GUI and its constellation of libraries and utilities is probably the first place I’d start. Every time I log in using Cockpit (web interface), I can see the memory usage, and it never changes by much. The Roon demon itself only takes up maybe 200-300MB of memory.