Running Roon server on Linux here.
With the 952 build I’ve got regular crashes (every 15 minutes or so) with the following logs:
May 26 16:53:12 prince start.sh: System.Net.Sockets.SocketException (104): Connection reset by peer
May 26 16:53:12 prince start.sh: at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error, CancellationToken cancellationToken)
May 26 16:53:12 prince start.sh: at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource<System.Int32>.GetResult(Int16 token)
May 26 16:53:12 prince start.sh: at System.Threading.Tasks.ValueTask`1.ValueTaskSourceAsTask.<>c.<.cctor>b__4_0(Object state)
May 26 16:53:12 prince start.sh: --- End of stack trace from previous location ---
May 26 16:53:12 prince start.sh: at System.Threading.Tasks.TaskToApm.End[TResult](IAsyncResult asyncResult)
May 26 16:53:12 prince start.sh: at Sooloos.RnetJsonClient.<>c__DisplayClass65_0.<_BeginRead>b__0(IAsyncResult ar)
Can you look into this? This is super annoying.
@support any response? I’ve reported this 2 days ago and right now I can’t listen without continuous crashes.
Ok, can confirm this is a memory-leak
[ 9441.112703] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/roonserver.service,task=RoonAppliance,pid=984,uid=0
[ 9441.112828] Out of memory: Killed process 984 (RoonAppliance) total-vm:35070392kB, anon-rss:12722048kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:43192kB oom_score_adj:0
I appreciate you bringing this to our attention. I’m very sorry that we didn’t circle back to you before the U.S.-based tech support team signed off for the extended holiday weekend here.
A persistent fatal crash is beyond frustrating. The team is actively investigating this issue and we hope to have more information soon. The moderators have moved your thread into the consolidated thread where we will be posting updates about this issue.
Ever since build 952 I’ve been having Roon killed by the OOMkiller process. It happens about daily, and on one occasion killing the process also corrupted the database and needed a full reinstall. Running on a box with 8GB RAM, been stable until 952.
root@DietPi:~# service roon status
Unit roon.service could not be found.
root@DietPi:~# service roonserver status
● roonserver.service - Roon Server (DietPi)
Loaded: loaded (/etc/systemd/system/roonserver.service; disabled; vendor preset: enabled)
Active: failed (Result: oom-kill) since Wed 2022-06-01 03:19:19 AEST; 6h ago
Process: 53429 ExecStart=/opt/roonserver/start.sh (code=killed, signal=TERM)
Main PID: 53429 (code=killed, signal=TERM)
CPU: 8h 56min 2.549s
May 31 23:23:37 DietPi Roon Server: 07:49:48.035 Debug: PathForResource, filename: …/Appliance/RoonAppliance
May 31 23:23:37 DietPi Roon Server: 07:49:48.035 Debug: PathForResource, candidate: /opt/roonserver/Server/…/Appliance/RoonAppliance
May 31 23:23:37 DietPi Roon Server: Started
May 31 23:23:40 DietPi Roon Server: Not responding
May 31 23:23:40 DietPi Roon Server: aac_fixed decoder found, checking libavcodec version…
May 31 23:23:40 DietPi Roon Server: has mp3float: 1, aac_fixed: 1
May 31 23:23:45 DietPi Roon Server: Running
Jun 01 03:19:19 DietPi systemd: roonserver.service: A process of this unit has been killed by the OOM killer.
Jun 01 03:19:19 DietPi systemd: roonserver.service: Failed with result ‘oom-kill’.
Jun 01 03:19:19 DietPi systemd: roonserver.service: Consumed 8h 56min 2.549s CPU time.
It seems to just suddenly get itself in a knot and die. Mine has been playing for the last hour or so, and then suddenly the music stopped (despite showing as still playing on the remotes). Checking top tells me that the CPU and MEM usage are skyrocketing.
Does a restart of the service fix it? Not sure if this is the same as my past issue here.
Came here to report that there appears to be a memory leak, using Roon in docker on Unraid, works great with the exception of the creeping memory leak that eventually brings the whole box down. The workaround seems to be to restart the Roon docker server every day. I’ll likely have to move Roon Server to a different set up as it’s not viable via the docker I’m using. Hard to tell what’s going on, but grafana confirms that Roon basically eats away at the Ram till there’s none left, I have 32GB on that machine.
For the most part yes, although as I’ve noted one of the kills corrupted the database and needed a full removal and reinstall. I’ve been taking to rebooting the box rather than restarting the service, but either way I think my issue is different to yours. Roon seems to behave normally for a while, and then within an hour or so of listening something causes cpu and memory to spike and it just climbs and climbs until the OOMkiller kills it. Can get a little sketchy though, today my music died and it then took me 10 minutes to ssh into the box while it had no resources (but before it had killed Roon).
I don’t think that will help, mine is dying within a few hours of a full reboot (but was rock solid before this build).
That’s the behavior I see, although it takes longer, as I have 32GB of RAM, which Roon consumes, but it takes less than 24 hours. I’ve stopped the docker container whilst I rethink. I have other options but it’s annoying to not be able to leave something like this running all the time. I’m going to try on my Mac and see if the behavior persists. It’s a little frustrating, there are countless threads about this across a variety of OS / Machine combinations.
I wish there was a way to manually roll back. (I haven’t got the old build installer lying around unless its cached somewhere I can’t find)
Came here to look for an issue I’ve been having as of late. Roon user for several years now, never seen this problem so bad until this latest version. I leave roon client (build 952) running on my Mac (Macbook Pro 14") and over the course of a few hours it becomes almost unresponsive. Buttons are slow / non responsive and search queries just sit there. Closing the app and launching again resolves it for a little time. Definitely seems like a memory leak. Roon is running on a dedicated roon core OS linux box elsewhere.
Just adding my own voice to the issue. I am a brand new Roon user, still within my trial period. I have experienced the same memory leak running both the steefdebruijn/docker-roonserver container and on an Ubuntu Server. My machine has an i5-2500 and 32GB DDR4 RAM for a library of ~35k tracks.
Edit: I’m not sure if this is related, but sometimes my CPU usage also spikes incredibly high even not when listening to any media (and scanning/analysis has already completed) until I close the Windows Roon program, which drops it back down to < 1%.
Hi @connor ,
Do you have an update?
I’m sure the team is working hard on this issue, but I think it would be appreciated by your customers if there is a little bit more communication about this issue. Has the problem been found? Is there a fix in the works? What is the ETA?
Right now I’ve got this build for about a week and it crashes about every 15-25 minutes when playing music. That in itself is ‘rather unpleasant’, and the lack of communication isn’t improving the experience.
The problem is still very much alive and kicking. I am restarting my core daily now - since it becomes unusable. It does not react to anything anymore.
Yeah. Mine does the same where OOMKiller kicks in. When this happens, the database automatically gets corrupted and I need to do a clean reinstall to fix it.
Oh no! Same problem here too. My installation decided to join the party yesterday evening:
Seems like the CPU getting overexcited was the start of it:
This was despite installing 952 some days ago without drama previously:
Running the Roon app for Synology on a DS418Play.
I’m having similar issues on a Roon ROCK running 952. Over time all functionality slows down. After I reboot the NUC or restart the Roon Server Software, it runs OK for a while. Currently doing 1-2 reboots a day.
Same problem. Running Roon Server Build 952 on dedicated Ubuntu 20.04.4 LTS. Running fine for more than a year until recent update. Problem is that once a day the RoonAppliance process likes to gobble up all the CPU and memory and becomes unresponsive.