Transmission and Sickrage doesn't run at machine startup

Hi, I have this installation:

###Rpi 1B (#1):

  • OSMC

###Rpi 1B (#2):

  • Transmission
  • Couchpotato
  • Sickrage

###HD disk:

  • Connected to wireless router (SMB filesystem)

I have several bugs. In this thread a want to face some systemd faliures. At startup Rpi 2 Couchpotato runs but Sickrage and Transmission does not.

Problem 1. Transmission start

This is the status after start Rpi 2. Transmission seems to be running, but its web interface is unreachable:

$ systemctl status transmission-daemon
● transmission-daemon.service - Transmission BitTorrent Daemon
   Loaded: loaded (/lib/systemd/system/transmission-daemon.service; enabled)
   Active: active (running) since jue 2017-05-25 17:17:19 CEST; 47min ago
 Main PID: 372 (transmission-da)
   Status: "Idle."
   CGroup: /system.slice/transmission-daemon.service
           └─372 /usr/bin/transmission-daemon -f --log-error

If I try to get error logs:

$ /usr/bin/transmission-daemon -f --log-error
[2017-05-25 18:37:39.169 CEST] UDP Failed to set receive buffer: requested 4194304, got 327680 (tr-udp.c:78)

After reload it runs OK:

systemctl reload transmission-daemon

Problem 2. Sickrage start

Unlike Transmission, Sickrage is not running at machine startup:

$ systemctl status sickrage
● sickrage.service - SickRage Daemon
   Loaded: loaded (/etc/systemd/system/sickrage.service; enabled)
   Active: failed (Result: timeout) since jue 2017-05-25 17:55:53 CEST; 11min ago
  Process: 319 ExecStart=/opt/sickrage/SickBeard.py -q --daemon --nolaunch --datadir=/opt/sickrage (code=killed, signal=TERM)

After start command it runs OK:

$ sudo service sickrage start


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.

Reboot and see if this works.

1 Like

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:

[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=/opt/sick$

[Install]
WantedBy=multi-user.target

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