FS#31478 - [transmission-cli] Add "After=network.target" in the .service file dof systemd

Attached to Project: Arch Linux
Opened by Paolo (palmaway) - Sunday, 09 September 2012, 09:57 GMT
Last edited by Bartłomiej Piotrowski (Barthalion) - Friday, 15 July 2016, 07:43 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Ionut Biru (wonder)
Tom Gundersen (tomegun)
Anatol Pomozov (anatolik)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 15
Private No

Details

The transmission daemon, when started as a service at boot with systemd, usually refuses connections from remote clients. The service starts accepting connections if restarted after boot time with

# systemctl restart transmission.service

This is probably due to the fact that the service starts before the network is properly set up, resulting in the impossibility to open port 9091 for external connections.

This is confirmed by the fact that adding the [Unit] configuration option:
After=network.target
solves the issue.

Package version: 2.61-3

Steps to reproduce:
- enable transmission as a systemd service on boot
- try to connect to the external interface (host:9091)
This task depends upon

Closed by  Bartłomiej Piotrowski (Barthalion)
Friday, 15 July 2016, 07:43 GMT
Reason for closing:  Upstream
Comment by Paolo (palmaway) - Sunday, 09 September 2012, 10:04 GMT
Ok, I realize that I have been a little unclear. By "Remote connections" I mean connections from external GUI's/web interfaces (that happen on port 9091, by default), and not from other bit-torrent clients on the port configured for the p2p protocol.
Comment by Christoph Sturm (globalmatador) - Monday, 04 March 2013, 18:04 GMT
what's a good way to get this fixed? I have to edit my transmission service file after every package update right now
Comment by Oleg (moonman) - Friday, 12 April 2013, 13:14 GMT
Im on the phone, but read in archwiki under systemd. In short create service with the same name under /etc/.... use ".include=path to original" and below only put your modifications. This way you wont have to modify original service all the time. Hope it makes sense
Comment by Paolo (palmaway) - Friday, 03 May 2013, 14:57 GMT
@Oleg: since this is something that should be there by default, why force all the users to make a custom config file just to have the thing working? The config file provided in the package should work out of the box. What you propose is a workaround, but not a fix...
Comment by Oleg (moonman) - Friday, 03 May 2013, 23:21 GMT
@Paolo: i agree. I was just trying to help Chriatoph as he was looking for a fix without editing the original service with wvery update.
Comment by Anatol Pomozov (anatolik) - Saturday, 01 June 2013, 14:48 GMT
I also was annoyed by this bug, adding "After=" to systemd config fixes the issue (restarted twice - transmission UI works). Is there any chance to submit the fix into repo so everyone can enjoy transmission without this network issue?

The bug is open 9 months already but it is not resolved yet. What is the reason of this stuck? Is there any additional issue that should be clarified?
Comment by Emilio Cafè Nunes (shinil35) - Sunday, 07 July 2013, 11:20 GMT
Another work-around:

cd /etc/systemd/system
mkdir transmission.service.d
cd transmission.service.d
nano startup_fix.conf

Now write into the file:

[Unit]
After=network.target

Just save and do systemctl daemon-reload

This will persist at package updates.
Comment by Anatol Pomozov (anatolik) - Monday, 15 July 2013, 18:30 GMT
It is sad to see that Arch maintainers did not do any progress in 9 months.

Anyway, systemd configuration has been moved upstream. I filed ticket there https://trac.transmissionbt.com/ticket/5421
Comment by I Said Socks (socks) - Saturday, 27 July 2013, 06:24 GMT
This issue can be closed since it's fixed by upstream in transmission 2.81.
Comment by Eric Wang (enihcam) - Wednesday, 31 July 2013, 07:59 GMT
btw, smbd.service from samba is also having this issue.
Comment by Max (silverhammermba) - Wednesday, 29 October 2014, 06:28 GMT
  • Field changed: Percent Complete (100% → 0%)
I still have this problem. The service is enabled on boot, but transmission-remote will not connect until I restart it.

I saw that the After was changed to network-pre.target so I tried changing it to just network.target but that doesn't work either.
Comment by Mauro Santos (R00KIE) - Monday, 03 November 2014, 13:41 GMT
If things are going to be changed, then everything that depends on the network should also come after iptables/ip6tables, transmission included.
Comment by Bastien Traverse (Neitsab) - Tuesday, 14 April 2015, 22:50 GMT
I am not affected by this bug. I have transmission start automatically at boot on a server with its default systemd service, and everything's all right -- it has been so since I installed it in January 2015.

Can affected users describe their configuration:
- is the dedicated 'transmission' user used or their own user? (as per https://wiki.archlinux.org/index.php/Transmission#Choosing_a_user)
- what is the network setup: ethernet via DHCP, wireless via NetworkManager...? https://wiki.archlinux.org/index.php/Transmission#Autostart_at_boot has a note about some dhcpcd setup which require adding a "Requires=network.target" directive to the service. See if this helps.
Comment by Max (silverhammermba) - Wednesday, 15 April 2015, 03:44 GMT
I definitely still have the problem. I am using ethernet via dhcpcd.

Adding Requires=network.target appears to fix it, but I'm curious as to why this is not included by default. Would that break something for people who aren't using DHCP?
Comment by Bastien Traverse (Neitsab) - Wednesday, 15 April 2015, 09:38 GMT
That may be it, since I'm using netctl to handle a static Ethernet link (manually defined IPv4 and autoconfigured IPv6).
After adding [Unit]\nRequires=network.target with `systemctl edit transmission` and restarting the box I didn't experience any issue, so at least for netctl it seems to be good.

The notable absence of developer/maintainer intervention on this bug report may indicate that alerts are not sent properly by Flyspray. I suggest somebody affected by the issue brings it to attention on the mailing list (arch-general should do it) asking for comment and linking here.
Comment by Andrew Gaydenko (student975) - Wednesday, 15 April 2015, 11:37 GMT
At my case replacing "After" with "Require" still results in "Network is unreachable" in a journal.

... 14:21:04 ... systemd[1]: Starting transmission daemon...
... 14:21:05 ... systemd[1]: Started transmission daemon.
... 14:21:05 ... transmission-daemon[224]: sendto: Network is unreachable
... 14:23:10 ... systemd[1]: Stopping transmission daemon...
Comment by Bastien Traverse (Neitsab) - Wednesday, 15 April 2015, 12:22 GMT
@student975: the wiki advice is to *add* the "Requires=network.target" directive to the service file, not _substitute_ it to "After"; also I noticed you wrote "Require" not "Requires" with an s, maybe it's a typo but I prefer to raise it up because that may invalidate the directive.

So please try to put back the "After" directive in the original service file and use # systemctl edit transmission to add

[Unit]
Requires=network.target

in the extension file, then **reboot your system** so that the whole network stack is reinitialized.
Comment by Andrew Gaydenko (student975) - Wednesday, 15 April 2015, 13:02 GMT
OK, now I use an overriding of .service file instead of replacing with custom .service file. At the moment I have got:

# cat /etc/systemd/system/transmission.service.d/override.conf
[Unit]
Requires=network.target

[Service]
ExecStart=
ExecStart=/usr/bin/transmission-daemon -f -a some.sub.net.* -utp -C -b -o -g /some-path/sys/config --incomplete-dir /some-path/parts -L 64 -l 8 -w /data/torrent/files -e /some-path/sys/log.txt --log-error

At boot I still get "Network is unreachable", and service restarting results in working service.
Not sure it is important, the system is running on flash stick, while /some-path is RAID 1 hdds.

Comment by Bastien Traverse (Neitsab) - Wednesday, 15 April 2015, 20:10 GMT
Two thoughts:
- maybe the problem has to do with the custom command line. You can try the default ExecStart line and see if it works, or to put your parameters in a config file and see if it changes something;
- do you by any "chance" have an IPv6 link? IPv6 is slow to setup via DHCP and transmission has a few issues with it (see the results of https://trac.transmissionbt.com/search?q=network+unreachable&noquickjump=1&changeset=on&milestone=on&ticket=on&wiki=on).
I access the webUI via my webserver which acts as a proxy (SSL termination...) and I had to change the http://localhost:9091 address to an explicitly IPv4 one (http://127.0.0.1:9091/) to workaround a bug with IPv6.

Also, please enable the debug log verbosity option to have more info: see https://trac.transmissionbt.com/wiki/EditConfigFiles#Misc and maybe https://trac.transmissionbt.com/wiki/EnvironmentVariables#Transmission-SpecificVariables if it doesn't help.
Comment by Andrew Gaydenko (student975) - Thursday, 16 April 2015, 19:51 GMT
Bastien,

1. I have tried keep ExecStart intact with - unfortunately - the same result (that is "sendto: Network is unreachable").
2. What does "have IPv6 link" mean exactly? To detect the above error it is sufficient to look at systemd journal without accessing to Web-UI at all. I haven't caught the idea, sorry.
3. I'll report regarding more log verbosity later.
Comment by Andrew Gaydenko (student975) - Thursday, 16 April 2015, 20:05 GMT
OK, have tried debug log level. Interesting part during boot:


[2015-04-16 22:55:51.892 MSK] Port Forwarding (NAT-PMP) initnatpmp failed. Natpmp returned -3 (cannot get default gateway ip address); errno is 0 (Success) (natpmp.c:75)
[2015-04-16 22:55:51.892 MSK] Port Forwarding (NAT-PMP) sendpublicaddressrequest failed. Natpmp returned -10 (send() failed); errno is 89 (Destination address required) (natpmp.c:75)
[2015-04-16 22:55:51.892 MSK] Port Forwarding (UPnP) upnpDiscover failed (errno 101 - Network is unreachable) (upnp.c:99)
[2015-04-16 22:55:51.892 MSK] Port Forwarding (UPnP) UPNP_GetValidIGD failed (errno 0 - Success) (upnp.c:235)
[2015-04-16 22:55:51.892 MSK] Port Forwarding (UPnP) If your router supports UPnP, please make sure UPnP is enabled! (upnp.c:238)
[2015-04-16 22:55:51.892 MSK] Port Forwarding State changed from "Not forwarded" to "???" (port-forwarding.c:92)

And this one during manual restart (after the last one web UI became accessible):

[2015-04-16 23:00:47.962 MSK] Port Forwarding (NAT-PMP) initnatpmp succeeded (0) (natpmp.c:70)
[2015-04-16 23:00:47.962 MSK] Port Forwarding (NAT-PMP) sendpublicaddressrequest succeeded (2) (natpmp.c:70)
[2015-04-16 23:00:55.963 MSK] Port Forwarding (UPnP) UPNP_GetValidIGD failed (errno 0 - Success) (upnp.c:235)
[2015-04-16 23:00:55.963 MSK] Port Forwarding (UPnP) If your router supports UPnP, please make sure UPnP is enabled! (upnp.c:238)
[2015-04-16 23:00:55.963 MSK] Port Forwarding State changed from "Not forwarded" to "Starting" (port-forwarding.c:92)
[2015-04-16 23:00:55.963 MSK] Port Forwarding (NAT-PMP) readnatpmpresponseorretry failed. Natpmp returned -7 (the gateway does not support nat-pmp); errno is 111 (Connection refused) (natpmp.c:75)
[2015-04-16 23:00:55.963 MSK] Port Forwarding State changed from "Starting" to "???" (port-forwarding.c:92)




Comment by Anatoly Smaznov (javum) - Thursday, 23 April 2015, 08:19 GMT
I'm was dancing for a long time with this problem. I had dhcpcd wired network setup.
And transmission periodically won't start at boot. "Requires=network.target" has no effect.
Then I have moved to netctl and no I haven't any problem for 2 months...
Comment by Bastien Traverse (Neitsab) - Thursday, 23 April 2015, 10:50 GMT
@Andrew: to me your debug log confirms that your network is indeed "not sufficiently up" when transmission starts. The first three lines are the relevant ones, especially "cannot get default gateway ip address". Not much can be done network-wise if the gateway cannot be reached (e.g. no DNS queries, which may explain the "Destination address required" error on 2nd line).

Two possible solutions:
- stick with dhcpcd and try to replace "After=network.target" by "After=network-online.target" (as per https://wiki.freedesktop.org/www/Software/systemd/NetworkTarget/);
- or as javum suggested, make the switch to netctl and forget about this issue :-)

I wonder whether setting a static config in /etc/dhcpcd.conf (see https://wiki.archlinux.org/index.php/Dhcpcd#Fallback_static_profile for inspiration and man dhcpcd.conf for the full optionss) would solve the issue. Something else to try!
Comment by Andrew Gaydenko (student975) - Thursday, 23 April 2015, 11:36 GMT
Have tried "After=network-online.target" (as well as "Requires=network-online.target") with the same result, that is restarting is still needed.
As for netctl, unfortunately, at the moment I"m not ready to play with netctl, sorry. The system is running headless somewhere near a ceiling, and any network problem would result in.. well, to avoid flooding I'll omit this long list of movements :)
Comment by Bastien Traverse (Neitsab) - Monday, 27 April 2015, 10:58 GMT
Haha I'm out of guess then, I suggest you try Transmission bug tracker then to see if they can help debug this!
Comment by Andrew Gaydenko (student975) - Monday, 25 May 2015, 12:07 GMT
I must to report at the moment the issue has gone for me. Sorry, can not say which update has resolved the issue. override.conf contains Exec redefinition only with the aim to use own directories.
Comment by Anatol Pomozov (anatolik) - Saturday, 31 October 2015, 05:13 GMT
@Andrew: to use online network you need to enable it as 'systemctl enable systemd-networkd-wait-online.service' or 'systemctl enable NetworkManager-wait-online.service'. See http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
Comment by Andrew Gaydenko (student975) - Saturday, 31 October 2015, 12:17 GMT
@anatolik, thanks for the suggestion. Have tried. Unfortunately it doesn't rise transmission WEB service up. It seems some changes must be done to a whole network configuration. At the moment:

[root@nas ~]# systemctl status systemd-networkd
● systemd-networkd.service - Network Service
Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:systemd-networkd.service(8)
[root@nas ~]# systemctl | grep -i network
network.target loaded active active Network

That is the system doesn't use systemd-network (as well as NetworkManager) services. But the system is connected with, I guess, some default settings (with network.target).
Comment by Andrew Gaydenko (student975) - Saturday, 31 October 2015, 13:15 GMT
... so I have continued the game and just installed NetworkManager on the NAS (without enabling NetworkManager-wait-online.service). During ~6-7 reboot (or turn off/turn on) iterations after each boot the transmission WEB interface was accessible. So, I guess, the transmission service must demand something NetworkManager (or networkd - haven't play with it) do supply.
Comment by Mindaugas Tamosevicius (min_t) - Sunday, 22 November 2015, 17:53 GMT
TL;DR - Bastien, setting a static config in /etc/dhcpcd.conf resolved the issue.
Maybe the problem is with dhcpcd? It tells that network is available too early?

Full story:

Headless server, DHCP static lease, fresh install from 2015.11.01 iso.

Added
[Unit]
After=network.target
Requires=network.target

- no effect.

Checked that dhcpcd.service disabled and dhcpcd@enp1s0.service enabled.

Added static config (and noarp option) for enp1s0 in /etc/dhcpcd.conf - problem solved.

Maybe the problem is with dhcpcd? Dhcpcd tells systemd that network is ready too early?
Comment by Bastien Traverse (Neitsab) - Sunday, 22 November 2015, 18:05 GMT
@Mindaugas - Interesting, it seems indeed dhcpcd has a part in triggering this issue. I'd suggest pinging its developers -- http://roy.marples.name/projects/dhcpcd/index, see the bottom for mailing list instructions -- and linking here. Roy Marples is one of the most friendly upstreams I have dealt with, surely he'll try to reproduce this or know a bit more about which part of the network initialization may cause this.

Loading...