I am trying to make the transmission-daemon start on boot on my Raspberry Pi model B using systemd. I am at a point where I can stop and start the daemon using systemctl, but automatic startup on boot is not working yet.

I have created the unit file /etc/systemd/system/transmission.service:

Description=Transmission daemon

ExecStart=/usr/bin/transmission-daemon -f


I have enabled the service using:

sudo systemctl enable transmission.service

Unfortunately...no joy on reboot. However, a manual start works:

sudo systemctl start transmission.service

What am I doing wrong? I am on the latest Raspbian Jessie.

EDIT (2015/10/16)

According to the output of ps aux and systemctl status transmission.service, the daemon is up and running. However, I cannot reach the web interface. If I stop the running instance of the daemon and restart it manually, then I am able to reach the web interface.

On request, here are the outputs for ps aux and netstat after rebooting the Pi:

https://dl.dropboxusercontent.com/u/29638164/ps_before.txt https://dl.dropboxusercontent.com/u/29638164/netstat_before.txt

and here are the same outputs after manually restarting the daemon:

https://dl.dropboxusercontent.com/u/29638164/ps_after.txt https://dl.dropboxusercontent.com/u/29638164/netstat_after.txt

by using:

$ killall transmission-daemon
$ sudo systemctl start transmission.service
  • What does systemctl status say after booting? Or systemctl --failed? – Bram Oct 14 '15 at 4:44
  • Hmmm...it appears 0 units failed...odd... – Aeronaelius Oct 14 '15 at 4:52
  • So what is the status of the service? Also what is the default target? Perhaps you are not in the mukti user target? – Bram Oct 14 '15 at 4:55
  • I do not know how to check or add myself to the multi-user target :( . According to systemctl status transmission.service the service is active (running). However, I am not able to reach the web-client via my browser. If I do a systemctl stop followed by a systemctl start I am able to reach the web-client. – Aeronaelius Oct 14 '15 at 5:03
  • 1
    Then please update your question. Add process listing and netstat output after booting and after restarting the service. – Bram Oct 14 '15 at 5:08

Requires=network.target tells systemd that this service needs network connections activated at some point, but does not specify this service should be started up only after the networking is up.

(Yes, there are services that can deal with network interfaces appearing, getting reconfigured and/or disappearing while the service is running. For those, Requires=network.target would work just fine. In the modern world, with hot-plugging and IPv6 becoming more common, perhaps more services should be like that.)

From systemd.unit(5) man page (emphasis mine):

Note that requirement dependencies do not influence the order in which services are started or stopped. This has to be configured independently with the After= or Before= options. If a unit foo.service requires a unit bar.service as configured with Requires= and no ordering is configured with After= or Before=, then both units will be started simultaneously and without any delay between them if foo.service is activated. Often, it is a better choice to use Wants= instead of Requires= in order to achieve a system that is more robust when dealing with failing services.

If you want to specify that the service should start only after networking is up and all the interfaces have their IP addresses, you should do something like this instead:


From systemd.special(7) man page:


Units that strictly require a configured network connection should pull in network-online.target (via a Wants= type dependency) and order themselves after it. This target unit is intended to pull in a service that delays further execution until the network is sufficiently set up. What precisely this requires is left to the implementation of the network managing service.

| improve this answer | |

Transmission-daemon can't bind a port because the network interface hasn't got the IP address yet. Assuming the IP address is going to be 192.168.xxx.xxx the issue can be resolved by adding ExecStartPre option to transmission-daemon systemd unit with the following command

ExecStartPre=/usr/bin/timeout 120 sh -c "until ifconfig | grep -m 1 '192\.168'; do sleep 1 ; done"

More details can be found here

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.