RPi, Rasbian, how to start transmission on boot?

How can I start transmission every time the RPi boots up?

My RPi has been running for years, but I have to restart transmission every time there is a power outage.

I have tried

sudo apt-get install transmission-daemon
sudo update-rc.d -f transmission-daemon

But it does not boot into transmission.

I have done a lot of experimenting on this sd card version of Raspbian, so there may be some messed up settings.

Just having transmission installed doesn't autostart it, it will only autostart if it has been included in a start script.

What you can do is create a script to run transmission, I think it would be something like:

#/bin/sh
/usr/bin/transmission-gtk

Make that owned by root, place it in your /etc/init.d directory, make it executable, and then run update-rc.d:

sudo update.rc.d <script-file-name> defaults

There are a variety of options one can use with update-rc.d, however I believe that using "defaults" should be sufficient. Then reboot your system to verify that it works. As an advance check, you can run the script manually to verify that it will run transmission, therefore leaving the final check to see that it auto-runs at boot.

OK, I made a start script: "starttx" located here: /etc/init.d/starttx

#!/bin/bash
transmission-gtk -g /home/pi/.config/transmission

The file is executable and owned by root.

It starts transmission using the correct configuration file.

Then I ran:

sudo update-rc.d starttx defaults

Got an error message

insserve: warning: script 'starttx' missing LSB tags and overrides

On reboot, transmission-gtk is not running.

I went to /etc/init.d/skeleton and edited the skeleton file lines as follows:

DESC="Automatic start of transmission-gtk"
NAME=starttx
DAEMON=usr/bin/$NAME
DAEMON_ARGS="-g /home/pi/.config/transmission"

It is not starting up transmission on boot.

Man I hate this new startup script method!

If you perform a web search and put in that entire error string, but just taking the specific name of your script out, you'll see a variety of solutions, many of which I'm not all too happy/comfortable with. And FURTHER, they pretty much ALL say "this is a warning only, your script is running, but to remove the warnings ..." Hogwash!! I say! Very sorry that something like this has come up.

Here's "MY" old school and there may be a handful of people who chime in and offer something different or try to fix what you have.

## In /etc/init.d/ directory place your script and again have it owned by root
## In /etc/rc5.d/ directory create a symbolic link to the /etc/init.d/ script.
## The conventions to use (I recommend) are to use ../init.d/<scriptname> not /etc/init.d/<scriptname>
## for the target de-reference, and then use S99 as the start.  The 'S' means to start when entering
## runlevel 5.  The '99' is a sequence, the sequences are in numerical order, no problems if there are
## other S99 script links.  You merely want to run this when the system is mostly up and running.
## Example:
$ cd /etc/init.d
$ ls -l starttx
$ -rwxr-xr-x 1 root root ### Feb 16 2015 starttx
$ cd ../rc5.d
$ sudo ln -s ../init.d/starttx S99starttx

And then of course validate that the link is created in the /etc/rc5.d directory and looks like:

lrwxrwxrwx 1 root root ## Feb 17 2015 S99starttx -> ../init.d/starttx

Any links in this directory showing the S will be run when runlevel 5 is entered. And there will be maybe some discussion/argument about whether or not you should run this out of a different level, or use rcS.d. Read the arguments, but use what works for you and alter if you find compelling arguments. I kind of get tired of the changes and the justifications when ultimately one thing does end up working.

Originally Posted by rtmistler ## Example: $ cd /etc/init.d $ ls -l starttx $ -rwxr-xr-x 1 root root ### Feb 16 2015 starttx $ cd ../rc5.d $ sudo ln -S ../init.d/starttx S99starttx lrwxrwxrwx 1 root root ## Feb 17 2015 S99starttx -> ../init.d/starttx [/code]

Note: the -S should be lower case in

sudo ln -s ../init.d/starttx S99starttx

I got to this point, then

sudo update-rc.d starttx defaults

which resulted in a lot of errors

update-rc.d: using dependency based boot sequencing
insserv: warning: script 'K01starttx' missing LSB tags and overrides
insserv: warning: script 'starttx' missing LSB tags and overrides
insserv: There is a loop at service starttx if started
insserv: There is a loop between service minissdpd and mountall if started
insserv:  loop involving service mountall at depth 5
insserv:  loop involving service checkfs at depth 4
insserv: There is a loop between service minissdpd and mountnfs if started
insserv:  loop involving service mountnfs at depth 8
insserv:  loop involving service networking at depth 7
insserv:  loop involving service urandom at depth 6
insserv: There is a loop between service minissdpd and mountnfs if started
insserv: There is a loop between service minissdpd and mountall-bootclean if started
insserv:  loop involving service mountall-bootclean at depth 1
insserv:  loop involving service kbd at depth 10
insserv: Starting starttx depends on minissdpd and therefore on system facility `$all' which can not be true!
(repeat 98 times)
insserv: Max recursions depth 99 reached
insserv:  loop involving service avahi-dnsconfd at depth 1
insserv: Starting starttx depends on minissdpd and therefore on system facility `$all' which can not be true!
(repeat 99 times)
insserv: exiting now without changing boot order!
update-rc.d: error: insserv rejected the script header

Yes, lowercase 's'. Sorry about that.

Well you don't need to run the update-rc.d, I hope you don't have that mis-perception and were just reporting the former errors. If you create the symbolic link in rc5.d or rcS.d then it should just start when you boot and the whole update-rc.d is non-used. The purpose of that update-rc.d is to automate those scripts and administer the startup. It adds some header comment lines which it cares about, and not sure if any other parts care about it. Scripts themselves ignore # comment lines, and I believe the kernel boot flow just recognizes the S and K and numbers for when it enters rc2.d, rc3.d, rc4.d, rc5.d and so forth.

Which logs should I look at to find out why transmission is not starting?

I have been trying a number of things to start transmission on boot.

The init.d and rc.d scripts start on boot, before the user is established, and before the graphic screen is started.

There are other options, such as /etc/profile, ~/.profile, ~/.bashrc. I tried to run an executable script in each of these and it would not start correctly. Running the script in /etc/profile led to the gui of transmission visible but the rest of the screen (window) did not appear. The other scripts did not do anything. I tried a sleep 60 delay, to allow the rest of the screen to start up before executing transmission-gtk, with no results.

I am still interested if there is a way to start up an application after the user has been logged in automatically, and after the startx screen has completed. I know other distros have a startup folder that allows for easy start up of applications on boot, but it does not seem like it is an easy thing to do on a Raspberry Pi.

If you're running Raspberian and kept the default desktop there should be an xinitrc file somewhere like /etc/X11/xinit/xinitrc (don't quote me on that, do a find files to locate where it is).

The format of that file is shell script and it really should just start the xsession, but you can also add the start of transmission to that. Similarly you can add like the start of a terminal to that so that when you log in and start X it would start a terminal. I'd actually experiment with that first so you can verify that it does the terminal first and then modify that to start transmission.

As far as auto logging in, I don't know the exactness of that and recommend a web search like "raspberian auto login" I just did that and there's a bunch of hits, ones that look real too not just inappropriate adds to get rich quick or various self improvement offerings.