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
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
|
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
Friday, 15 July 2016, 07:43 GMT
Reason for closing: Upstream
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?
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.
Anyway, systemd configuration has been moved upstream. I filed ticket there https://trac.transmissionbt.com/ticket/5421
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.
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.
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?
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.
... 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...
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.
# 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.
- 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.
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.
[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)
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...
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!
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 :)
[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).
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?