Successful Roon Client Connection after Roon Server Upgrade depends on Server Start Method

[CRo (Chris)]

Hello @support,

This is a followup to a previous post about Roon Server not being reachable after updating.

I want to show the cause of the problem, and a workaround.

I would like to find a better solution, with your help.

tj;dr: How Roon Server is started determines if the clients are able to connect. It would seem to be a certificate or authentication issue based on environment.

Symptoms:
After every update of the Roon Server (initiated when a Roon Client is started and an update is detected), the Roon Client can’t connect to the Roon Server anymore, permanently.
Client being on Android, Windows, and Ropieee
Roon Server being on Linux, RHEL 8.4

Repeatability:
All updates to Roon Server 1.8.

Initial Solutions:
Restore the entire database from backup.
Create a new Roon installation (re-scan all media.)

Although better than nothing, these are terribly intrusive and take a very long time, in the case of re-scanning the music.

Install Environment description:
As per Linux installation instructions, one can install Roon Server in any path and directory that one wants.

The easy install script from http://download.roonlabs.com/builds/roonserver-installer-linuxx64.sh defines:

• Installation in /opt/RoonBridge or /opt/RoonServer
• Data is stored in /var/roon/RoonBridge or /var/roon/RoonServer

A manual installation (without the Easy script) was used (ie. unpacking the Linux Roon Server contents) in order to follow the guidelines for Red Hat Enterprise Linux, which defines that third party binary services and applications are installed in /srv instead of /opt. This is relevant for SELinux security contexts [BTW, no, it is not an SELinux problem - disabling SELinux does not make a difference].

In this case Roon Server is installed in /srv/RoonServer:

$ ls /srv/RoonServer/
Appliance  check.sh  RAATServer  RoonGoer  RoonMono  RoonServer  Server  start.sh  VERSION

This being Linux, it doesn’t have a registry, and there’s nothing wild about that path.

Identification of the actual problem:

There are two ways to start Roon Server;

1. As a foreground process in the running shell via the “start.sh” script.
   → The clients connect, things work fine after update
2. Via a systemd or init.d service script
   → Loss of connectivty after update

Why is that? Good question! I don’t know.

Here is the systemd service unit file I have, which is the one provided by Roon Labs with the path modified for my installation:

$ cat /etc/systemd/system/roonserver.service 
[Unit]
Description=RoonServer
After=network-online.target

[Service]
Type=simple
User=root
Environment=ROON_DATAROOT=/srv/RoonServer
Environment=ROON_ID_DIR=/srv/RoonServer
ExecStart=/srv/RoonServer/start.sh
Restart=on-abort

[Install]
WantedBy=multi-user.target

As can be seen, it’s the same and the only Roon Server installation on the Linux Server (in /srv/RoonServer).

If I do this:

# pwd
/srv/RoonServer
# ./start.sh 
00:00:00.001 Warn:  get lock file path: /tmp/.rnsgem0-
00:00:00.065 Trace: [childprocess] using unix child process
Initializing
Started
aac_fixed decoder found, checking libavcodec version...
has mp3float: 1, aac_fixed: 1
Running

Then things work just fine after the latest upgrade.

If I do this:

# systemctl start roonserver
# systemctl status roonserver
● roonserver.service - RoonServer
   Loaded: loaded (/etc/systemd/system/roonserver.service; disabled; vendor preset: disabled)
   Active: active (running) since Wed 2021-08-04 13:09:10 CEST; 5s ago
 Main PID: 132128 (start.sh)
    Tasks: 57 (limit: 203910)
   Memory: 116.2M
   CGroup: /system.slice/roonserver.service
           ├─132128 /bin/bash /srv/RoonServer/start.sh
           ├─132135 /srv/RoonServer/RoonMono/bin/RoonServer --debug --gc=sgen --server RoonServer.exe
           ├─132148 /srv/RoonServer/RoonMono/bin/RoonAppliance --debug --gc=sgen --server RoonAppliance.exe -watchdogport=43371
           ├─132154 /srv/RoonServer/Server/processreaper 132148
           └─132198 /srv/RoonServer/RoonMono/bin/RAATServer --debug --gc=sgen --server RAATServer.exe

Aug 04 13:09:10 grendel.home systemd[1]: Started RoonServer.
Aug 04 13:09:10 grendel.home start.sh[132128]: RD: /srv/RoonServer
Aug 04 13:09:10 grendel.home start.sh[132128]: RD: /srv/RoonServer
Aug 04 13:09:10 grendel.home start.sh[132128]: 00:00:00.001 Warn:  get lock file path: /tmp/.rnsgem0-
Aug 04 13:09:10 grendel.home start.sh[132128]: 00:00:00.067 Trace: [childprocess] using unix child process
Aug 04 13:09:10 grendel.home start.sh[132128]: Initializing
Aug 04 13:09:10 grendel.home start.sh[132128]: Started
Aug 04 13:09:11 grendel.home start.sh[132128]: aac_fixed decoder found, checking libavcodec version...
Aug 04 13:09:11 grendel.home start.sh[132128]: has mp3float: 1, aac_fixed: 1
Aug 04 13:09:15 grendel.home start.sh[132128]: Running

Then the Roon Clients don’t find the server.

Right, what is the difference?

[beka]

Hey @CRo,

Thanks for this post! We appreciate it.

I’ve gone ahead and looped in our technical team, so they can chime in.

Please, bear with us for a little while until they get a chance to take a look

[noris]

Hi @CRo ,

Thanks for reaching out and for your patience here while we got a chance to look over your detailed notes here.

I’m going to consult with our QA team on this one, but can you please confirm if you see the same behavior on a standard Ubuntu install as well?

Or is only RHEL 8.4 impacted by this startup behavior? Let us know if you have a chance, thanks!