Intermittent loss of connectivity to Roon Server and music stops

Okay, I have done some additional digging through my log files and have the following timeline…

19th October 2020:

Announcement that [Roon 1.7 (Build 667) is Live!](Roon 1.7 (Build 667) is Live!) on the Roon website.

22nd October 2020:

First evidence of SIGSEGV error in my journal files.

$ grep "SIGSEGV" journal.txt 
Oct 22 05:01:00 Roon-Media start.sh[19765]: Got a SIGSEGV while executing native code. This usually indicates
Oct 22 05:01:00 Roon-Media start.sh[19765]: Got a SIGSEGV while executing native code. This usually indicates

1st November 2020:

Upgraded my core from Ubuntu 18.04 to 20.04

Aug 18 07:27:10 Roon-Media kernel: Linux version 5.4.0-42-generic (buildd@lgw01-amd64-023) (gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)) #46~18.04.1-Ubuntu SMP Fri Jul 10 07:21:24 UTC 2020 (Ubuntu 5.4.0-42.46~18.04.1-generic 5.4.44)
Nov 01 15:06:36 Roon-Media kernel: Linux version 5.4.0-52-generic (buildd@lcy01-amd64-022) (gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)) #57~18.04.1-Ubuntu SMP Thu Oct 15 14:04:49 UTC 2020 (Ubuntu 5.4.0-52.57~18.04.1-generic 5.4.65)
Nov 01 15:34:40 Roon-Media kernel: Linux version 5.4.0-52-generic (buildd@lgw01-amd64-060) (gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)) #57-Ubuntu SMP Thu Oct 15 10:57:00 UTC 2020 (Ubuntu 5.4.0-52.57-generic 5.4.65)
Nov 19 19:53:26 Roon-Media kernel: Linux version 5.4.0-53-generic (buildd@lcy01-amd64-007) (gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)) #59-Ubuntu SMP Wed Oct 21 09:38:44 UTC 2020 (Ubuntu 5.4.0-53.59-generic 5.4.65)

From this I can ascertain that the symptoms were present prior to my upgrade to Ubuntu 20.04. It also appears as though the update to Roon build 1.7 (667) introduced the problem into my system as evidenced in the timeline above.

1 Like

@Andreas_Philipp1 As it stands today I agree with your conclusion but I believe that there were changes to the code in Roon 1.7 667 that are the root cause of these crashes. I believe that Ubuntu Desktop is a viable product to use with Roon Server and the QA team needs to perform some root causes analysis and fix their code. I also believe that this is likely impacting other users on Linux based platforms but they don’t necessarily have the luxury of being able to troubleshoot in the same way due to being locked down (think Nucleus, SonicTransporter etc.). Hopefully the QA team will be able to come up with a resolution for this as a priority. As my current setup is only stable because I have applied a workaround I will not be marking this question as solved until the root cause is addressed.

2 Likes

I agree on all points. What we have implemented is a workaround, not a solution. And it doesn’t help people on other platforms who might experience similar problems. Let’s hope Roon QA can find the ultimate root cause of the problem and make Roon a more stable software. Thank you for your help digging in your logs and trying out the workaround. There are already other users trying out the same.

And thank you for making sense of the logs and bringing the workaround to the table.

I am now at over 72 hours without recording a crash in the log files, music has been playing constantly without a break for about 60 hours. I am declaring with significant confidence that the changes made to my network configuration are key to the crashes not occurring any more. I have reviewed log files going back to April 2020 and they tell a story. The crashes started within a couple of days of 667 being announced, they were not present on my system (as proven by the log files) prior to October 22nd 2020. My core then underwent an upgrade from Ubuntu 18.04 to 20.04 on November 1st 2020 and the crashes remained, I also performed a kernel upgrade last week and there was no improvement. It wasn’t until I moved the network configuration from NetworkManager to networkd that the server stabilized. Hopefully the QA team can come up with a resolution to this issue quickly, if I was a betting man I would wager that these crashes are being experienced by more Roon customers than the handful detailed in these support posts over the course of the past week or so.

1 Like

More users affected:

I wonder if those reporting disconnections on ROCK are experiencing something related. Would be nice to have some feedback from Roon @support.

I wonder if these symptoms are directly addressed in the 710 update? It would be nice to hear something from @support regarding this.

Indeed. It would be good to hear @support on the status of this issue.

As an update, I have upgraded my SonicTransporter and Microjukebox to the very latest thanks to Andrew’s help at Small green Computer, and I have updated to latest Roon build. Unfortunately, the drops are now within in 1-2 songs, so actually the problem I have is getting worse with the updates. Maybe 1.8 will fix it. Support is indeed looking into my situation, so we will see if it’s just me or part of a global issue. I’m still not sure that NetworkManager is addressed in the updates.

Paul, you know there is a workaround you can implement on your Ubuntu 20.04.1, while Roon QA hopefully figures out the root cause of the problem and comes up with a solution. No need to get used to those crashes and disconnects.

Some days ago I opted to install Ubuntu Server on my Roon core server, and run it using the stock configuration, without any changes to network management. On Ubuntu Server the ethernet interfaces per default are being managed by networkd, but still use DHCP. On my router I have configured a lifetime of 24 hours and address reservation, and so once every 24 hours there is a DHCP lookup. Until now (4 days) its has been running very stable.

Yes, I know the work around.

The context is my frustration about support.

During this past year I logged 5 issues of which only 1 has been addressed. All the others have vanished without response after having supplied all the requested info. I’m getting tired of this.

Also, the current update may have changed or added a new problem, as many library files disappeared- Andrew thought this may be a Roon database corruption but I’m noticing others have had this issue since the last update. I did do a restore which restored the playlists but then led to rapid and frequent connect / disconnect cycles. More so than before the last two updates.

Hi everyone,

I just wanted to let everyone know that our QA team is actively investigating this and I’ll follow up as soon as we have more information on this. Thanks!

Thank you!

@dylan - it has now been 8 days since I last recorded a crash in my log files, the music has not stopped playing once without human interaction either.

Today I reconfigured the networking setup on my Ubuntu Server box to use NetworkManager both for the ethernet and WiFi interfaces, but using a static IP and turning off DHCP4 for the ethernet interface. I believe there is no problem using NetworkManager, as long as DHCP4 of active interfaces is turned off. The coming days will tell…

The Netplan configuration is as follows:

network:
   version: 2
   renderer: NetworkManager
   ethernets:
      enp3s0:
         dhcp4: false
         addresses: [10.0.4.116/24]
         gateway4: 10.0.4.1
         nameservers:
            addresses: [10.0.4.116, 8.8.8.8, 8.8.4.4]
   wifis:
      wlp2s0:
         dhcp4: true
         access-points:
            "your SSID":
               password: "your password"

It’s now 72 hours since I reconfigured the ethernet interface of my Roon core server back to be managed by NetworkManager. I can report that all is well, there have been no more crashes of RoonAppliance. It seems that so long as the interface doesn’t use dhcp4 there is no problem.

So, for those who run their Roon core on Ubuntu Desktop or other distributions derived from Ubuntu or dependent upon NetworkManager, the simple recommendation is to configure the ethernet interface with static IP, gateway and DNS servers, turning effectively off the use of DHCP4 for this interface.

On Ubuntu, you can do this simply by modifying the Netplan configuration in etc/netplan. E.g., this does the job:

network:
   version: 2
   ethernets:
      enp3s0:
         dhcp4: false
         addresses: [10.0.4.22/24]
         gateway4: [10.0.4.1]
         nameservers:
            addresses: [8.8.8.8, 8.8.4.4]

Use the correct device name of your ethernet device and your corresponding IP and gateway addresses. Be careful with the indentation and use spaces, not tabs, to indent. Try the configuration with sudo netplan try and, if all is well, install and activate it with sudo netplan apply.

Users on Ubuntu Server should not be affected and need not reconfigure the ethernet interface.

1 Like

Many thanks for the continuing investigation and reporting.

Hi @dylan , what has become of this?

Hi @Andreas_Philipp1

This is something I spoke about with the team this morning. We are still working on this, but I don’t have any specific updates I can provide just yet. We’ll be sure to provide more information as soon as we can. Thanks!