INTERACT FORUM
More => Old Versions => JRiver Media Center 23 for Linux => Topic started by: mwillems on July 23, 2017, 08:45:46 am
-
Here's a systemd service that will automatically start jriver on boot as your user (after the display manager loads), and if JRiver should crash, restarts it within 10 seconds. This will work best on systems with autologin, but because of the restarting feature, should work fine even if it has to wait for you to login. You want to put your username in the "user" spot, and put the following text in a file at /etc/systemd/system/jriver.service:
[Unit]
Description=JRiver
After=display-manager.service
[Service]
Type=simple
Environment=DISPLAY=:0
User=your_user_here
ExecStart=/usr/bin/mediacenter23 /MediaServer
Restart=always
RestartSec=10
KillSignal=SIGHUP
TimeoutStopSec=45
[Install]
WantedBy=graphical.target
Some technical notes: this presumes you're running on your actual display, not a virtual display generated by a VNC client. If you are using such a virtual display, substitute the display variable in the Environment section, and change the "After" line to refer to the name of the systemd service you're using to start your vnc server, but note that VNC virtual displays may not work correctly anymore with MC since 22.0.36.
In that vein, here's a service to start x11vnc to allow remote access to your actual display on boot. It similarly will restart if it crashes. You want to put your username in place of both of the "your_user_here" placeholders below, create a file at /etc/systemd/system/x11vnc.service, and put the following text there:
[Unit]
Description=x11vnc
After=display-manager.service
[Service]
Type=forking
Environment=DISPLAY=:0
User=your_user_here
ExecStart=/usr/bin/x11vnc -rfbauth /home/your_user_here/.vnc/passwd -display :0 -geometry 1920x1080 -auth guess -forever -bg
Restart=always
RestartSec=10
[Install]
WantedBy=graphical.target
Technical notes: this presumes that you've already setup a VNC password. If you want to run without a password remove the -rfbauth flag and the path following it. If you want to set a password run the following command replacing "your_password" with your password:
x11vnc -storepasswd your_password ~/.vnc/passwd
Once you've got the services in place you can set them to start on boot by typing
sudo systemctl enable jriver.service
and/or
sudo systemctl enable x11vnc.service
-
Nice.
You're doing a great job to add another merit badge to your collection.
Will keep this in mind when I the opportunity to tinker presents.
-
I would like to note for others that display-manager.service is a link to lightdm.service (at least in Ubuntu 16):
lrwxrwxrwx 1 root root 35 Sep 7 22:03 display-manager.service -> /lib/systemd/system/lightdm.service
At least on my system mediacenter23 did not start reliable (sometimes yes, more-often no):
Replacing the line:
After=display-manager.servicewith:
After=lightdm.serviceseems to work better.
Also I would recommend to replace:
Restart=alwayswith:
Restart=on-failureThis way one can shutdown MC without it being restarted automatically.
-
I would like to note for others that display-manager.service is a link to lightdm.service (at least in Ubuntu 16):
lrwxrwxrwx 1 root root 35 Sep 7 22:03 display-manager.service -> /lib/systemd/system/lightdm.service
At least on my system mediacenter23 did not start reliable (sometimes yes, more-often no):
Replacing the line:
After=display-manager.servicewith:
After=lightdm.serviceseems to work better.
display-manager.service is always linked to the display manager for the distro. On ubuntu it's lightdm, on debian its gdm (by default), on fedora gdm, etc. So display-manager.service is guaranteed to point to the right place, and is the correct general purpose answer. As a symlink it's interchangeable with the thing linked to, so it's would be very unusual if you're actually seeing different results with "after=lightdm.service," but if you are there is something peculiar about your install.
Additionally the always auto-restart should be bringing MC up shortly if it doesn't succeed in loading the first time (unless you changed it to "on failure" as you described, because systemd doesn't always do a good job of distinguishing failure-based shutdowns)
Also I would recommend to replace:
Restart=alwayswith:
Restart=on-failureThis way one can shutdown MC without it being restarted automatically.
I initially tried that, but my experience was that some of MC's failure modes do not successfully hook "on-failure", so I'd get crashes where MC would never respawn. I was using this primarily on headless systems, so "always" was a safer choice. If you want to stop MC on a system with the "always" option, there's always "systemctl stop jriver.service"
-
Ubuntu 17.10 is switching to gdm from lightdm.
-
Additionally the always auto-restart should be bringing MC up shortly if it doesn't succeed in loading the first time (unless you changed it to "on failure" as you described, because systemd doesn't always do a good job of distinguishing failure-based shutdowns)
I initially tried that, but my experience was that some of MC's failure modes do not successfully hook "on-failure", so I'd get crashes where MC would never respawn. I was using this primarily on headless systems, so "always" was a safer choice. If you want to stop MC on a system with the "always" option, there's always "systemctl stop jriver.service"
Ah! that's the reason why you had "always" in the restart option. I am somewhat too lazy to type "systemctl ..." stopping MC.
On the other hand it does not feel like a final solution if I assume it always starts 10 seconds later ...
-
... but if you are there is something peculiar about your install.
Of course it's always the fault of the others :P
-
Of course it's always the fault of the others :P
To be clear, I'm not employed by JRiver, I'm just a user like you. A systemd symlink to a service should be 100% identical to the service pointed to, and if it's not then something very strange is happening (at the systemd or POSIX level, not at the jriver level).
-
To be clear, I'm not employed by JRiver, I'm just a user like you. A systemd symlink to a service should be 100% identical to the service pointed to, and if it's not then something very strange is happening (at the systemd or POSIX level, not at the jriver level).
Of course you'r right. I just wondered because doing a systemctl list-dependencies shows lightdm and not display-manager.
The reason why it now works better on my server could be the missing gravity of the sun here in Vienna (at time of writing) or simply because systemd is not bug free.
And, don't we know it all better ... how often have you already said ".... it should ..." regarding SW systems!?
-
I did a clean install of Debian Stretch 9.3 and it appears that jriver.service does not start anymore. Any ideas?
-
I did a clean install of Debian Stretch 9.3 and it appears that jriver.service does not start anymore. Any ideas?
Did you enable it? What does the journal tell you about jriver.service?
-
Some extra info: I did the same install like before (when it worked): installed only the Debian 9 base system plus Standard system uitlities and then I installed only gnome-session and some applications like gedit, sudo, abiword, gnome-disk-utility etc.. Now at Debian 9.3, when I start jriver.service and I ask for the status, it returns with: no protocol specified and unable to open the X display device:0. I know that device:0 is correct. Some problem with permissions/authority?
Update: the output of: echo $DISPLAY = :0
-
What happens if you start JRiver manually using the normal command-line invocation?
How about if you try to start the service manually from inside gnome using systemctl start jriver.service? How about systemctl restart jriver.service?
You don't mention whether or not you installed or enabled a display manager; if you did not do so, that is almost certainly the problem; how are you starting gnome-session and/or xorg? Piecemealing a desktop environment in debian (as opposed to using tasksel or the installer) can lead to many surprises as many components are pre-configured to rely on other components that they expect to be installed; the fact that it worked once is no guarantee it will work again.
This sounds like either a display manager issue or an xsession permissions issue, but we'll get to the bottom of it.
-
I did a clean install again and now it works. Not sure what went wrong. When the problem occured I was able to start mediacenter 23 /mediaserver from the command-line. If I'm not mistaken, gnome-session comes with gdm3. Thanks for your willingness to help. Much appreciated!