The question is ¿How can I get running both Sickrage and Transmission at machine startup? and ¿How can I diagnose the problem? Any help will be appreciated.
Hi. This kind of problem can occur if systemd starts the program too early during system startup.
Since these two are not critical to the functioning of the OS, you can wait until startup has reached what used to be called runlevel 3 and is now called multi-user.target.
Edit /lib/systemd/system/transmission-daemon.service and in the [Unit] section comment our any line that begins After= and then add the line After=multi-user.target. Repeat the same for sickrage.service, though it looks to be in /etc/systemd/system.
Thank you! Problem 1, solved. Transmission runs at reboot.
However, Sickrage timeout faliure still present. Unlike Transmission, there is no After line to comment at Sickrage service. After add it now, it looks like:
@Tom_Doyle Using After=network.target is likely to start the process earlier than After=multi-user.target, which waits until the basic OS is up and running. So mine is an even more conservative approach.
I took a look at the SickRage page and their systemd .service file does not contain a Type= line, so would default to Type=simple. whereas @aitor’s specifies Type=forking and runs it as a daemon. It might be the case that Type=forking is incorrect (and is certainly not used on the SickRage systemd example). You’ll need to experiment.
I was basing my reply on the systemd file which has been posted, as it had not been provided before. I maybe wrong, but doesn’t:
After=multi-user.target
conflict with:
WantedBy=multi-user.target?
If my understanding of systemd is correct, doesn’t Wantedby now make sickrage a want of multi-user.target? Wouldn’t this possibly create a bit of a loop (which may explain the timeout), being as sickrage is now waiting for for multi-user.target but is also now a dependency of multi-user.target?
You are right, #2 has Raspbian GNU/Linux 8 (jessie). Although OSMC is part of the ecosystem, this specific machine has not OSMC. Therefore, maybe this question exceed the topic of this forum. Please, if this is the case, tell me.
In other hand, I thought this systemd problems are derived from follow a tutorial in this forum:
So, the reasonable step was to ask here first. Indeed, the info in this thread is being very useful for me.
I guess unless The Boss says No, if we can get it to work on Raspbian, then that information should be useful for OSMC. But getting logs will be difficult.
I think your first step should be to use the “official” systemd .service file from the page Tom linked to. Try it with their ExecStart line first then try your own. See if that works. Rename your sickrage.service file to something else.
Ok, thank you! Yesterday, I tried that default sickrage service setup. After that, sickrage hangs a few seconds after run. I am installing SR from scratch again. I’ll try this service setup again in a while.
EDIT: Default service init is the same I have (different from systemd.service from page Tom liked to).
When I do $ sudo systemctl start sickrage.service timeout error persists.
If I stop the service (even, when service is already stopped), then, I can start it with success: sudo systemctl stop sickrage.service && sudo systemctl start sickrage.service
So, starting from previous default service (github linked), A possible hack, at my level of knowledge, could be to make a root delayed cronjob, when reboot, something like:
After uninstall and install sickrage following that tutorial (including dependencies install command) I get same timeout error. Even, with explicit command sudo service sickrage start. I tried a lot of configurations for sickrage.service, without forget sudo systemctl daemon-reload after changes, including yours (I changed installation directory to /opt/sickrage instead /home/osmc/.sickrage and changin user/group to sickrage/sickrage because i did previously sudo chown -R sickrage:sickrage /opt/sickrage).
Ok! that line works, just with explicit command sudo service sickrage start (at reboot I get timeout). So, I am in the same point that in the beginning
I forget to mention, sorry. With pi:pi I get a permission faliure:
may 27 19:46:32 raspberrypi python[3820]: Data directory must be writeable: /opt/sickrage
may 27 19:46:35 raspberrypi systemd[1]: sickrage.service: control process exited, code=exited status=1
may 27 19:46:35 raspberrypi systemd[1]: Failed to start SickRage Daemon.
Because I did previously sudo chown -R sickrage:sickrage /opt/sickrage
