Hello,
recently I've been testing transmission-daemon. Overall I'm very pleased with the combo 2.13 and Transmission-remote-gui, but I think there is an error/bug related to reloading the settings.json file in conjunction with blocklists. I post my observations here, so others can trie to recreate the errors, before submitting a bug ticket.
I use an external shell script to modify the settings.json, thus binding the daemon to an dynamic IPv4 network interface. This is a workaround until the patch from ticket #2313 gets adapted. The script gets triggered when the network interfaces IPv4 address changes. Then the settings.json file is edited (via sed, "bind-address-ipv4" value changed) and then the daemon is signaled via "killall -HUP transmission-daemon", as advised in the Wiki. This process works fine.
But in conjunction with local blocklist files I encountered an error. For testing, I use three distinct blocklists. It seems, that right after the "bind-address-ipv4" has been changed and the daemon receives the signal, trackers announces are triggered (which is, in principle, good). Now apparently the blocklists get reloaded as well (see this comment on ticket #2119). But the daemon connects to new peers before (all?) the blocklists seem ready, because right after the SIGHUP it connects to peers that should have been blocked. By manually stopping and restarting the torrent via gui, I can purge those peers. More annoyingly, this behavior can be not be reproduced all the times, it appears that high load on the system triggers the error more frequently.
Steps to reproduce:
1) Get local blocklist files (Bluetack or whatever).
2) Create additional blocklist file with one line "All:0.0.0.0-255.255.255.255"
3) Set "bind-address-ipv4" and enable blocklist in settings.json
4) Get a well seeded torrent, f.e. this NetBSD release on Linuxtracker.org
5) Start the daemon and add the torrent, it shouldn't connect to any peer thanks to step 2
6) Change IP address on the interface. The daemon now shouldn't be able to connect to the trackers as well.
7) Manually edit the "bind-address-ipv4" to reflect changes in 6), save changed settings.json
8) Send SIGHUP
I put up the debug log (obfuscated IPs) on pastebin.
I triggered the whole process on "14:23:24.221" (no problem) and on "14:35:25.600" (in that case one peer could connect), hence I paused the download on "14:39:27.903" and restarted it again, thus purging the peer. In the first case, all blocklists are reloaded before the trackers could send new peers, while in the second case one blocklist gets loaded, then the trackers respond, and after that the remaining blocklists are loaded (at least that's how it was written to the log file, but the time-stamp is identical on all this events).
Any input on this would be really appreciated!