Transmission and Sickrage doesn't run at machine startup

Hi,

I would try:

[Unit]
Description=SickRage Daemon
After=network.target

Thanks Tom.

1 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.

1 Like

Hi Dilithedog,

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?

Thanks Tom.

1 Like

If that were true, then transmission would be in the same position and would enter a loop. But it doesn’t.

Sickrage was failing to start before and that is still the case. Running grab-logs -J might help.

$ grab-logs -J
-bash: grab-logs: no se encontró la orden (No order found)

I’m trying to find info about grab-logs, unsuccessfully. Can you provide some refer? thanks!

1 Like

Is the RPi #2 running OSMC? You said that #1 has OSMC but didn’t say what’s on #2.

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.

1 Like

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).

Ok, after a fresh SR install, these are the facts:

  • At machine startup, SickRage does not run, and status return the timeout error.
  • Good news: journalctl -xn now works and return: Sickrage timeout fail log - Pastebin.com
  • 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
  • In this case, journalctl -xn returns no error: https://pastebin.com/iNVYSp6b

After replace default service setup (that I linked it in GitHub) with the service in the page Tom linked to, there is no timeout error, but:

$ systemctl status sickrage.service
● sickrage.service - SickRage Daemon
   Loaded: loaded (/etc/systemd/system/sickrage.service; enabled)
   Active: failed (Result: start-limit) since sáb 2017-05-27 10:19:46 CEST; 28s ago
  Process: 1373 ExecStart=/usr/bin/env python2 /srv/sickrage/SickBeard.py --quiet --config /srv/sickrage/config.ini --datadir /srv/sickrage (code=exited, status=217/USER)
 Main PID: 1373 (code=exited, status=217/USER)

may 27 10:19:46 raspberrypi systemd[1]: sickrage.service: main process exited, code=exited, status=217/USER
may 27 10:19:46 raspberrypi systemd[1]: Unit sickrage.service entered failed state.
may 27 10:19:46 raspberrypi systemd[1]: sickrage.service holdoff time over, scheduling restart.
may 27 10:19:46 raspberrypi systemd[1]: Stopping SickRage Daemon...
may 27 10:19:46 raspberrypi systemd[1]: Starting SickRage Daemon...
may 27 10:19:46 raspberrypi systemd[1]: sickrage.service start request repeated too quickly, refusing to start.
may 27 10:19:46 raspberrypi systemd[1]: Failed to start SickRage Daemon.
may 27 10:19:46 raspberrypi systemd[1]: Unit sickrage.service entered failed state.

And $ journalctl -xn
Failed at step USER spawning /usr/bin/env: No such process
(entire log: Sickrage timeout fail log 2 - Pastebin.com )

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:

sudo crontab -e

and add

@reboot (sleep 300; systemctl stop sickrage.service && sudo systemctl start sickrage.service)&

This is not a clean solution, but maybe can work.

First, the github page you link to has 4 different configurations. Did you try them all?

Second, it took me 10-15 minutes to install sickrage and and get it running:using this thread.

osmc@osmc:~$ sudo systemctl status sickrage
● sickrage.service - SickRage Daemon
   Loaded: loaded (/etc/systemd/system/sickrage.service; enabled)
   Active: active (running) since Sat 2017-05-27 10:00:13 BST; 2s ago
 Main PID: 1572 (python)
   CGroup: /system.slice/sickrage.service
           └─1572 /usr/bin/python /home/osmc/.sickrage/SickBeard.py -q --daemon --nolaunch --datadir=/home/osmc/.sickrage

May 27 10:00:13 osmc systemd[1]: Started SickRage Daemon.

No timeouts. But I did make one change that I’ve already talked about.

Edit: Here’s the sickrage.service file. It works.

osmc@osmc:~$ cat /etc/systemd/system/sickrage.service 
[Unit]
Description=SickRage Daemon
After=multi-user.target

[Service]
User=osmc
Group=osmc
Type=forking
GuessMainPID=no
ExecStart=/usr/bin/python /home/osmc/.sickrage/SickBeard.py -q --daemon --nolaunch --datadir=/home/osmc/.sickrage

[Install]
WantedBy=multi-user.target
1 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).

At the time to writte these words, it looks like:

[Unit]
Description=SickRage Daemon
After=multi-user.target

[Service]
User=sickrage
Group=sickrage
Type=forking
GuessMainPID=no
#ExecStart=/opt/sickrage/SickBeard.py -q --daemon --nolaunch --datadir=/media/Bak/sickrage-datadir
ExecStart=/opt/sickrage/SickBeard.py -q --daemon --nolaunch --datadir=/opt/sickrage
#ExecStart=/usr/bin/python2.7 /opt/sickrage/SickBeard.py -q --nolaunch

[Install]
WantedBy=multi-user.target

:sweat::sweat::sweat:

Hi,

Just a guess here, from looking a difference between your systemd file & dllthedog’s. Try changing:

to

ExecStart=/usr/bin/python /opt/sickrage/SickBeard.py -q --daemon --nolaunch --datadir=/opt/sickrage

Thanks Tom.

P.S

Also have you tried changing the user and group to pi?

1 Like

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 :slight_smile:

Hi,

You could try:

User=pi
Group=pi

Thanks Tom.

1 Like

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

Just to say, thank you a lot for your help and time. I’m trying too at SickRage forums:
https://www.sickrage.ca/forums/forum/help-support/bug-issue-reports/raspberry-pi/34748-sickrage-timeout-error-at-machine-startup

Hi,

You probably have more success over at the sickrage forums, good luck.

Just out interest what prevents you from reverting the ownership of sickrage folder to pi:pi

sudo chown -R pi:pi /opt/sickrage

and starting the sickrage as pi:pi

User=pi
Group=pi

?

Thanks Tom.

1 Like

I installed sickrage in 15 minutes and it worked with just one extra line. I followed the instructions on the thread I linked to exactly. I didn’t try to change one thing, and it worked first time. It starts at reboot and I can access the web interface.

Instead, you did not follow the instructions in the thread exactly. You have created a new user, sickrage. You have placed your files in /opt. You did not use the correct ExecStart line until Tom suggested it to you. There are probably other things I don’t know about. And you don’t seem to have read the logs, since I’m sure there will be some kind of error shown there.

Sorry about that. I had reasons for doing that. First, the user was created some months ago, with the first install I did following the intructions of this forum. Second, I choose that directory because I have Transmission and Couchpotato there (as this instructions says) and I’m trying to get things ordered. I used the correct ExecStart the first time I try it, but it did’t work. I just try it AGAIN when Tom mention it and it worked, srprisingly, I don’t know why. There is a lot of variables I’ve been changing during the process. And I don’t know what logs must I to read. If you beleave I can access some logs, please, just mention it.

Further more, I change de user and other things ONLY after the default installation with your settings was tested unsuccesfully. After get the same timeout error, I decide to come back to /opt/ because reasons exposed.

Further more, When I see that your service have osmc:osmc, I think, obviously, it should be changed in a Rpi without this groups and users.

I was doing all my best, all my effort trying to follow your recomendations, as can be seen in this thread. If it is not enough, sorry, is my best. At the end, trying to not abuse of your time and help, I went to SickRage forum and kindly I said good bye.