To me this looks like it all starts with the NetworkManager restarting. Roon as a network dependent process seems to bail out then. I ask myself if the restarts of the NetworkManager also occur when Roon Server isn’t running at all?
I don’t have another Linux box to do tests nor can I easily port the Roon server to another PC, but this is something which should be relatively easy to debug. What I can do is try and restart NetworkManager and see what Roon server does…
I just restarted NetworkManager and Roon kept playing… wasn’t affected.
I am considering to do a clean reinstall of Ubuntu Server on my Roon Core box, to go back to a well-known standard configuration…
A couple of days ago I re-enabled IGMP snooping on my router and that, for better or worse, has no effect at all. My remotes can discover the server and work well either way. And the SIGSEGVs we see in the logs don’t have nothing to do with IGMP snooping as configured on our routers.
For many days I had no disconnection occur while playing music on the server. But it is necessary to understand what is triggering those events, to resolve the problem for those who experience this several times a day or hour.
Thank you for sharing that additional information, it certainly does looks strange that you are both getting similar errors. Let me check in with our QA team if they can provide additional context surrounding these traces.
Mine is static (address of Sonic Transporter)
@dylan - I use a reserved IP address
Mine is static with address reservation on the router.
Reading up on some current info with regard to network configuration under Ubuntu Linux, I seem to grasp the following:
From 18.04 onward, Ubuntu uses Netplan, a new network configuration tool.
On Ubuntu Desktop, the default is NetworkManager.
Conversely, on Ubuntu Server the default is networkd.
What we users with the SIGSEGV problem seem to have in common is that our network interfaces are being managed by NetworkManager, or so it seems from looking at syslog where always immediately before the segmentation error NetworkManger was active. This was pointed out by @BlackJack in this thread.
Even if we configure on our routers a reserved address for the Roon core server, the NetworkManager-configured interface still may be using DHCP4 calls to the router. To ensure that does not happen, we would have to configure the interface explicitly as static, using Netplan on the server. This is something I did not do on my machine.
I initially had installed my server using Ubuntu desktop, so NetworkManager was the default network management tool on my box. I yesterday decided to reinstall the Roon core server using Ubuntu server, so now the default management tool is networkd. It now has been up near 24 hours, and in syslog I haven’t seen any trace of NetworkManager - it isn’t active anymore. It still is little time to tell, but I haven’t had a SIGSEGV in those 24 hours.
Even now my network configuration uses DHCP4 calls to the server:
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 04:d9:f5:f2:f6:aa brd ff:ff:ff:ff:ff:ff inet 10.0.4.116/24 brd 10.0.4.255 scope global dynamic enp3s0 valid_lft 58251sec preferred_lft 58251sec inet6 fe80::6d9:f5ff:fef2:f6aa/64 scope link valid_lft forever preferred_lft forever
To turn off completely the use of DHCP4 I would have to configure the interface as static by a configuration file in /etc/netplan, using the YAML syntax demanded by the tool. I won’t do this for the moment, waiting a week or so to watch if under networkd I’ll see similar SIGSEGV events as there were under NetworkManager.
This is for those interested in learning a little bit more about the Ubuntu way of network configuration:
Flagging @support in case you haven’t seen this.
Hi, have you experienced more crashes of Roon? I am now going near 48 hours and it’s been very stable.
Here is a nice example of how to configure the ethernet interface to be managed by networkd instead of NetworkManager on Ubuntu Desktop. If you haven’t done so, you could try this and see if you can get rid of the problem while Roon figures out how to make Roon live in peace with Ubuntu’s NetworkManager - if this in the end is the cause of the problem we’re experimenting.
@Andreas_Philipp1 I had a 36 hour period without a fault being logged. Then I was listening last night and at about 8:20 the music cut. I am going to implement your suggestion this evening.
I wish you good luck! Once you have reconfigured your ethernet connection to be managed by networkd instead of NetworkManager, you should probably stop and disable NetworkManager for good. If you don’t need easy WiFi setup on this server, doing so should be safe. Anyway, it could always be re-enabled.
sudo systemctl stop NetworkManager.service sudo systemctl disable NetworkManager.service sudo systemctl stop NetworkManager-wait-online.service sudo systemctl disable NetworkManager-wait-online.service sudo systemctl stop NetworkManager-dispatcher.service sudo systemctl disable NetworkManager-dispatcher.service sudo systemctl stop network-manager.service sudo systemctl disable network-manager.service
I actually squeezed this in while drinking my tea for the morning so now I am on a fully configured networkd static IP address and NetworkManager is disabled. I have to go to work today but I have started Roon Radio to play from my local library while I am gone. I can check the logs remotely. Thanks for the quick links, it took me all of 2 sips from my tea cup to get this done.
Thanks for the updates here, @Andreas_Philipp1 & @Robem. Our QA team is looking into this internally, but please keep us informed on if the changes you made helped — It’ll help to confirm that we are on the right track.
Ubuntu Linux Desktop - How to configure your ethernet interface
I just want to document progress…
It has now been over 24 hours since the last crash was recorded in the syslog and apport log files, while this timeline is not unheard of by the evidence seen over the past week, I am definitely in the period where I would have expected a crash by now or for it to occur at any moment. Roon Radio has been playing local files without interruption for about 14 hours now as well.
The stability so far is looking promising but there’s now always the chance that I have jinxed myself. I will update again in due course.
In my case it’s been now about 60 hours and all is well. Will report again tomorrow.