Transmission auto-stop/auto-restart

Help and Support Raspberry Pi
1

Hi there,

(sorry, I could not find how to insert code properly, and it is not easy to read - I can edit my post if somebody tells me how to :blush: )

I used to use a few scripts on my previous Rpi1 (Xbian) to enable the auto-stop of transmission when the VPN connection gets lost, and restart transmission when the VPN is recovered. However, I cannot manage to make it work on my Rpi2 (OSMC). Could somebody have a look, and let me know if the folder used or code used are not suitable with OSMC ?

Step1: prevent Transmission to start alone
sudo update-rc.d -f transmission-daemon remove

(I get these messages:
insserv: warning: script ‘K01startSB.sh’ missing LSB tags and overrides
insserv: warning: script ‘startSB.sh’ missing LSB tags and overrides)

Step2: allow only the VPN_IP_@ to be used, by creating a template of the settings.json
sudo cp /etc/transmission/settings.json /etc/transmission/settings_template.json

sudo nano /etc/transmission/settings_template.json

changed line “bind-address-ipv4”: “0.0.0.0” by “bind-address-ipv4”: “VPN_IP_@”

sudo touch /etc/openvpn/up.sh
sudo chmod +x /etc/openvpn/up.sh
sudo nano /etc/openvpn/up.sh

Add:

'#!/bin/sh
/etc/init.d/transmission stop

sed s/IP_ADDRESS/$4/ /etc/transmission-daemon/settings_template.json > /etc/transmission-daemon/settings.json

/etc/init.d/transmission-daemon start

Step4: start the Step3 script only when the VPN is running

sudo nano /etc/init.d/startSB.sh

'#!/bin/sh
sudo openvpn --config /etc/openvpn/MyVPN/US.ovpn --script-security 2 --up /etc/openvpn/up.sh

Thank you very much,
Nikox

2

Transmission running on OSMC uses a systemd native service located at /lib/systemd/system/transmission.service. You’re trying to run the legacy /etc/init.d script which is going to cause you problems as they will conflict.

I’d suggest you have a read of the following article that explains service management with systemd as the commands you’re using such as update-rc.d and running the legacy init scripts are obsolete in systemd.

3

Thanks. I’ll look at this.

I just saw that my mpd and alsa are also located into the /etc/init.d folder by default. MPD seems to be working fine. Could that be a problem with further updates of OSMC ?

Thanks,
Nikox

4

Systemd does support legacy init scripts in /etc/init.d, and if no native systemd unit exists the commands like ‘systemctl start transmission.service’ automatically get mapped through to running the legacy init script however if a native systemd unit of the same name exists it takes precedence when you use the native systemctl command for starting/stopping services…

That’s why you don’t want to run the /etc/init.d scripts directly, because then you end up using the deprecated init script instead of the systemd unit. (It was never a good idea to run init.d scripts directly btw, on older systems you should use the service command)

So basically on a systemd system always use the systemd commands like systemctl to control services and it will automatically use the native systemd service or map the commands through to the legacy scripts when required.

5

Thank you. So if I want to execute a script at startup, where shall I place it, in /lib/systemd/system or /etc/systemd/system instead of /etc/init.d ?
Then, enabling an application at startup is clear, using sudo systemctl enable application , but how to execute a script at startup ?

Thanks
Nikox

PS: how to insert commands properly in this forum ?

6

Systemd units are not bash scripts, they are unit definition that have their own syntax. Have a look at some of the other unit files in /lib/systemd/system and you will get the idea.

http://www.freedesktop.org/software/systemd/man/systemd.service.html

/lib/systemd/system is for services/units provided by the OS distributor (eg either us or Debian) while /etc/systemd/system is for services/units provided by or customised by the Administrator, eg you. Any version of a unit that is in /etc/systemd/system takes precedence over those in /lib/systemd/system thus allowing you to customise the service units in a way that won’t be overwritten by OS upgrades.

As for executing an arbitrary script at startup (eg not a conventional daemon) you could either put it in /etc/rc.local, or you could write a very simple service unit file to go in /etc/systemd/system, and enable it so it runs during bootup.