grymster Posted November 25, 2016 Share Posted November 25, 2016 Hi all. After installation of transmission-daemon I got two issues. First one is "UDP Failed to set receive/send buffer". I did fix it by adding next two lines to /etc/sysctl.conf net.core.rmem_max = 16777216 net.core.wmem_max = 4194304 Second one is that RPC does not start on boot but only after manual restart of service after boot. I believe it's caused because transmission starts before network goes online. I tried to fix it by adding into /lib/systemd/system/transmission-daemon.service [unit] ... Wants=network-online.target After=network-online.target But it does not help. I did fix it by adding next two lines to /etc/rc.local sleep 30 service transmission-daemon restart But thing is that I don't like this solution. Here is the armbianmonitor -u output. And syslog in attachments. Any thoughts? syslog.txt Link to comment Share on other sites More sharing options...
gnasch Posted November 25, 2016 Share Posted November 25, 2016 this may be a stupid question but did you reload systemd config after modifying the file? systemctl daemon reload http://serverfault.com/questions/700862/do-systemd-unit-files-have-to-be-reloaded-when-modified best, gnasch Link to comment Share on other sites More sharing options...
grymster Posted November 25, 2016 Author Share Posted November 25, 2016 Of course. That's how I managed to get debug messages at first place. Link to comment Share on other sites More sharing options...
arox Posted November 25, 2016 Share Posted November 25, 2016 But thing is that I don't like this solution. Why ? It is a workaround and workarounds are always ugly. Anyway you will need to check and reinstall workarounds with every new release, so I generally place my workarounds entirely in rc.local and disable what doesn't work out of the box. Link to comment Share on other sites More sharing options...
grymster Posted November 25, 2016 Author Share Posted November 25, 2016 Why ? Because It's signal to Armbian developers to think about "Why is network-online.target raise before network actually goes online?" Link to comment Share on other sites More sharing options...
zador.blood.stained Posted November 25, 2016 Share Posted November 25, 2016 Because It's signal to Armbian developers to think about "Why is network-online.target raise before network actually goes online?" https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ Link to comment Share on other sites More sharing options...
grymster Posted November 25, 2016 Author Share Posted November 25, 2016 https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/Thanks but I did try this one too. No luck. Only longer boot I got Link to comment Share on other sites More sharing options...
zador.blood.stained Posted November 25, 2016 Share Posted November 25, 2016 Thanks but I did try this one too. No luck. Only longer boot I got That is because either NetworkManager or systemd-networkd is not used by default, so you cant' expect network-online.target to operate correctly in this environment. And I would recommend checking logs to determine why exactly Transmission fails to start correctly on boot before making assumptions and trying to fix a problem thay may not exist. Link to comment Share on other sites More sharing options...
grymster Posted November 28, 2016 Author Share Posted November 28, 2016 That is because either NetworkManager or systemd-networkd is not used by default, so you cant' expect network-online.target to operate correctly in this environment. And I would recommend checking logs to determine why exactly Transmission fails to start correctly on boot before making assumptions and trying to fix a problem thay may not exist. Transmission itself starts ok. Nov 25 14:26:40 localhost transmission-daemon[436]: [2016-11-25 14:26:40.562 MSK] Bound socket 13 to port 51413 on 0.0.0.0 (net.c:379) Nov 25 14:26:40 localhost transmission-daemon[436]: [2016-11-25 14:26:40.562 MSK] Bound socket 14 to port 51413 on :: (net.c:379) Problem is related to RPC Server part only: Nov 25 14:26:40 localhost transmission-daemon[436]: [2016-11-25 14:26:40.562 MSK] RPC Server Adding address to whitelist: *.*.*.* (rpc-server.c:824) Nov 25 14:26:40 localhost transmission-daemon[436]: [2016-11-25 14:26:40.562 MSK] RPC Server Serving RPC and Web requests on port 127.0.0.1:9091/transmission/ (rpc-server.c:1033) Nov 25 14:26:40 localhost transmission-daemon[436]: [2016-11-25 14:26:40.562 MSK] getaddrinfo: address family for nodename not supported (trevent.c:216) Nov 25 14:26:40 localhost transmission-daemon[436]: [2016-11-25 14:26:40.562 MSK] RPC Server Whitelist enabled (rpc-server.c:1037) And after manual restart I got it like this: Nov 25 14:27:27 localhost transmission-daemon[889]: [2016-11-25 14:27:27.223 MSK] RPC Server Adding address to whitelist: *.*.*.* (rpc-server.c:824) Nov 25 14:27:27 localhost transmission-daemon[889]: [2016-11-25 14:27:27.223 MSK] RPC Server Serving RPC and Web requests on port 127.0.0.1:9091/transmission/ (rpc-server.c:1033) Nov 25 14:27:27 localhost transmission-daemon[889]: [2016-11-25 14:27:27.223 MSK] RPC Server Whitelist enabled (rpc-server.c:1037) Link to comment Share on other sites More sharing options...
arox Posted November 28, 2016 Share Posted November 28, 2016 Isn't it a problem of lo interface up timing ? Link to comment Share on other sites More sharing options...
arox Posted November 28, 2016 Share Posted November 28, 2016 Isn't it a problem of lo interface up timing ? do you have : "127.0.0.1 localhost" in /etc/hosts Link to comment Share on other sites More sharing options...
grymster Posted November 28, 2016 Author Share Posted November 28, 2016 do you have : "127.0.0.1 localhost" in /etc/hosts Yes I do. Link to comment Share on other sites More sharing options...
arox Posted November 28, 2016 Share Posted November 28, 2016 Well, I had the recollection that rpc-based protocols couldn't work without it. Nevertheless if it is not a missing lo interface configured or a missing localhost name resolution, you could have a problem with a "missing portmapper" that is a missing rpcbind process ready to register RPC services, but it is only an idea. Link to comment Share on other sites More sharing options...
grymster Posted November 30, 2016 Author Share Posted November 30, 2016 Well, I had the recollection that rpc-based protocols couldn't work without it. Nevertheless if it is not a missing lo interface configured or a missing localhost name resolution, you could have a problem with a "missing portmapper" that is a missing rpcbind process ready to register RPC services, but it is only an idea. I believe you are right. I thought something like this too. I tried use "After=rpcbind.target" but it did not work too. Main questions: Why? And how to fix it? Link to comment Share on other sites More sharing options...
arox Posted December 2, 2016 Share Posted December 2, 2016 I believe you are right. I thought something like this too. I tried use "After=rpcbind.target" but it did not work too. Main questions: Why? And how to fix it? Well, you can either do reverse engineering on systemd, disable all unneeded crap and start it in /etc/rc.local, or try to guess what is wrong. As an example, I found out that my nfs mounting worked in an erratic way because I had not defined the server in /etc/hosts. So sometimes mounting worked (because in is defined in my DNS server), sometimes it worked if I forced the mount in /etc/rc.local, and sometimes in didn't work at all during boot ... A boot script to do the same thing as systemd should have about 20 lines and be easily manageable. With parallelism, you can never be sure of the order in which the things are done, and with dependencies to remote services, you aren't even sure it will boot. Every time I change a line, reboot fail but second reboot work ?!? Check you don't need external host name resolution with transmission at startup, try to force "service rpcbind start" in rc.local. Link to comment Share on other sites More sharing options...
grymster Posted December 2, 2016 Author Share Posted December 2, 2016 Check you don't need external host name resolution with transmission at startup, try to force "service rpcbind start" in rc.local. I gave up already. I disabled transmission in systemd and added delayed start of it in rc.local. Period. Link to comment Share on other sites More sharing options...
Recommended Posts