Hi @Robem / @Andreas_Philipp1,
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.
@Robem, @Lawrence_Klein, & @Andreas_Philipp1 — Is your Core set up with a static IP or DHCP? If DHCP, how often does it renew?
Mine is static (address of Sonic Transporter)
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.
Netplan can be configured to set an interface up directly with static address, or it can delegate management of the interface to one of two network daemons - NetworkManager or networkd.
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:
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.serviceI 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.
Thanks for the progress report!
I wish I could help you with your SonicTransporter… but I have no idea which Linux it uses and how it is configured.
We are trying to figure out a workaround for Ubuntu Linux which uses a network management tool called NetworkManager. This seems to cause problems with Roon, resulting in disconnects (Roon core server disconnects shortly from the network and reconnects seconds later).
Hopefully the QA team of Roon can find the root cause of the problem and a solution to it. This maybe will be of help to users of SonicTransporter, too.
I am now at 48+ hours without recording a crash in the log files and the music has been playing non-stop since I pressed play over 36 hours ago. I’m now feeling a level of confidence that this workaround successfully addresses the disconnects that I was experiencing.