Hi all,
I have installed several optional packages on my OSMC device (running June 2015 release), and I can not get them to auto start with "systemd".
It is strange, as if I start them manually through the terminal with "sudo systemctl start xxxx.service", they run without issue.
Here are their status entries:
osmc@osmc:~$ systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
* couchpotato.service loaded failed failed CouchPotato application instance
* sickrage.service loaded failed failed SickRage Daemon
* transmission-daemon.service loaded failed failed Transmission BitTorrent Daemon
Can you think of a reason why these would fail at boot, but not when started manually? How can I find the details of why these have failed?
Sunkai.
sudo systemctl status service-name.service will show you the reason for failure for an individual service.
sudo journalctl will show the system journal, this will probably have clues too.
Thanks @DBMandrake. This is what I got:
sudo systemctl status couchpotato.service:
systemd[255]: Failed at step EXEC spawning /mnt/external/backup/opt/CouchPotatoServer/CouchPotato.py: Permission denied
sudo systemctl status sickrage.service:
systemd[257]: Failed at step EXEC spawning /mnt/external/backup/opt/Sick-Beard/SickBeard.py: Permission denied
sudo systemctl status transmission-daemon.service:
transmission-daemon[254]: [2015-07-29 17:02:41.804 BST] transmission-daemon Error loading config file – exiting. (daemon.c:519)
All of the files in the error messages here are on an externally mounted USB disk (the python script files and the transmission configuration file).
Is there a way of delaying the start of these services until the disk is mounted, and the files are available?
I assume that is why I can start these services without error through an ssh session (the drive is mounted at this point).
I added the following to the failing units:
After=network.target media-27e7c712\x2d9c44\x2d495a\x2da6ea\x2d69172e412c49.mount
I am still getting error messages, though they have changed.
sudo systemctl -l status couchpotato.service:
systemd[260]: Failed at step EXEC spawning /mnt/external/backup/opt/CouchPotatoServer/CouchPotato.py: No such file or directory
sudo systemctl -l status sickrage.service:
systemd[263]: Failed at step EXEC spawning /mnt/external/backup/opt/Sick-Beard/SickBeard.py: No such file or directory
sudo systemctl -l status transmission.service:
- transmission.service
Loaded: not-found (Reason: No such file or directory)
Active: inactive (dead)
The transmission daemon did start (due to the binaries being on internal storage), but it has failed to find the configuration file for the same reason as the other services. It loads with its default configuration.
"/mnt/external" is a symlink to the external USB HDD mounted at "/media/27e7c712-9c44-495a-a6ea-69172e412c49/".
Is there another service that I should be waiting for that allows for symlinks to be followed? Is there a systemd response time limit that is being violated when trying to access files on a USB HDD?
Unfortunately there is no easy way to wait for an automount drive to mount - for the simple reason that the system can’t know in advance what drives to wait for. It’s not until udisks probes for connected disks and finds them that the system knows what drives are connected. The mount unit you are trying to wait for doesn’t exist before udisks probes for connected disks.
There’s really only a couple of solutions, one easy but hacky, the other a bit more solid.
The easy hack is to simply add a couple of seconds delay to the startup of your services (which you could do with ‘ExecStartPre = /bin/sleep 2’ or similar in the service) which will give the automounter time to do its thing.
Of course this would not be 100% reliable. The other way you could do it is manually mount the drive in /etc/fstab to another location under /mnt - this way the system knows to wait for the drive before starting services that rely on local file systems, however make sure that you use the nofail option otherwise leaving the drive unplugged would prevent the whole system booting.
Great suggestions @DBMandrake, thank you.
In the end, I just copied the files that were on the USB HDD to local storage, and launched the services from there.
Moving everything to local storage meant that each of my custom services would start as expected, reading the specified configuration files.
However, when 'transmission' is initialised this way, the peer discovery mechanism for 'magnet' links does not work in the application.
If a 'torrent' file is added through the web interface directly, peers are found and downloading commences.
If the service is restarted with 'sudo systemctl restart transmission-daemon.service', then 'magnet' link peer discovery begins to work again.
Any idea what may be interfering with the configuration of 'transmission' when it is started through the 'systemd' method?
I notice that there is a built in 'osmc' package for 'transmission' that can be added through the 'app store'. How does that initialise 'transmission'?