Deluge
I'm running deluge 1.3.13 on Debian linux. I plan to upgrade to 1.3.15 soon but it will be quite a while before I can upgrade to 2.x.
I've seen this asked a few times but never a proper answer given.
In thin client mode (Classic mode disabled in the gtk Interface settings), deluge itself starts the daemon and there doesn't seem to be any way to add the -L and -l command line arguments to deluged.
A workaround that occurs to me is to rename the deluged executable to deluged.bin, then creating a script called deluged to call deluged.bin with the logging arguments.
But, what is the proper way to do this?
[SOLVED] How to pass logging cmd line args to deluged in thin client mode
[SOLVED] How to pass logging cmd line args to deluged in thin client mode
Last edited by rickmacd on Thu Apr 23, 2020 9:04 pm, edited 1 time in total.
Re: How to pass logging cmd line args to deluged in thin client mode
Hi,
I'm not fully sure to understand your meaning: you're in a client-server mode so the GTK client runs on another computer right?
If so the Deluged daemon on the Linux box start on its own, best with systemd unit. You can add log level in the systemd unit.
On the other end, the GTK client can also be started with debug mode, but for client side issue only then. Simply launch it with the command line and appropriate log level.
Am I missing something?
I'm not fully sure to understand your meaning: you're in a client-server mode so the GTK client runs on another computer right?
If so the Deluged daemon on the Linux box start on its own, best with systemd unit. You can add log level in the systemd unit.
On the other end, the GTK client can also be started with debug mode, but for client side issue only then. Simply launch it with the command line and appropriate log level.
Am I missing something?
Re: How to pass logging cmd line args to deluged in thin client mode
Thanks for the reply!
Both are running on the one Linux host. IIRC I switched to this mode some time ago when I switched from Tranmission to Deluge. For some reason SickChill (which may have been called SickBeard or SickRage at the time) couldn't connect to the self-contained Deluge to add new torrents. When I switched to client-server mode it worked immediately.
Your surprise at this suggests that not many people do what I have done and this could be why it doesn't seem possible and previous answers missed the point and just gave links to the config docs. I implemented the work-around that I suggested and it works fine. I'll have to remember that it will get overwritten every time deluge gets an update if I need to keep it permanently.
I see that I had added logging args to the systemd script but it's not used. Ive forgotten now why not, but vaguely recall that when I tried that I found that when rebooting (after a power outtage for example) deluge somehow would start before the daemon and not connect. I have Deluge starting the daemon itself.
So, you could say that I ended up in this situation by not trying to solve the problems I encountered but the client-server mode has been working well for me. I do access it remotely, from an android phone app called TransDrone and occasionally the web-ui browser client.
Both are running on the one Linux host. IIRC I switched to this mode some time ago when I switched from Tranmission to Deluge. For some reason SickChill (which may have been called SickBeard or SickRage at the time) couldn't connect to the self-contained Deluge to add new torrents. When I switched to client-server mode it worked immediately.
Your surprise at this suggests that not many people do what I have done and this could be why it doesn't seem possible and previous answers missed the point and just gave links to the config docs. I implemented the work-around that I suggested and it works fine. I'll have to remember that it will get overwritten every time deluge gets an update if I need to keep it permanently.
I see that I had added logging args to the systemd script but it's not used. Ive forgotten now why not, but vaguely recall that when I tried that I found that when rebooting (after a power outtage for example) deluge somehow would start before the daemon and not connect. I have Deluge starting the daemon itself.
So, you could say that I ended up in this situation by not trying to solve the problems I encountered but the client-server mode has been working well for me. I do access it remotely, from an android phone app called TransDrone and occasionally the web-ui browser client.
Re: How to pass logging cmd line args to deluged in thin client mode
This is off topic, but the reason why I need to turn on logging in the demon is as follows. I find that my torguard proxy disconnects now and then, leaving my real IP exposed and I get nasty letters from my ISP. Perhaps it's because I'm running an old version of deluge, but instead of stopping the download deluge starts using my real IP and exposes me. I think v1.3.15 does this too. I couldn't find a Kill switch so I implemented my own simply by installing the IPstatusbar plugin which writes the IP address to the daemon log as well as the status bar. I have a lightweight Cron job that runs currently every 15 seconds, grabbing the demon log for any change to the IP address. If it changes to my own real IP address, I pause all of the torrents using the deluge-console command line program. Watching my torrents from another deluge instance running on a laptop as a test, I see that pausing the torrents is good enough and I don't need to Halt the demon itself.
Re: How to pass logging cmd line args to deluged in thin client mode
The start (localhost)daemon option from connection-manager, does as per the source of deluge/ui/client.py just use subprocess.Popen to call deluged with port and config args, so since no path is specified, then I'm guessing you could add a shell-script named deluged to be placed in your user bin dir and have that dir added to PATH as in the beginning of PATH so takes precedence(done by most already) and then in that file specify full path to deluged, logging and "$@". You could of-course also just patch the source directly, but gets lost on updates.
However, I'd much more suggest going with shamael's suggestion of using systemd, and adding it there from drop-in file or something which survives updates. I didn't understand what you meant by deluge starting before the daemon though, as your reasoning for not using that, as you don't start the UI automatically, atleast not usually.
Last, your reasoning for logging, was to overcome and detect proxy issues, but I'd instead highly suggest installing ltconfig plugin and enabling force_proxy and anonymous_mode, which are available natively in deluge2. This will stop all connections if not going through the defined proxy(and scrub other identifying info away from packets sent) so effectively a kill-switch for proxies. The most important of these, force_proxy, was deprecated and instead used now as default behavior in libtorrent 1.2.x, but deluge 1.3.15 doesn't support over 1.1.x, but not an issue if using ltconfig as stated.
However, I'd much more suggest going with shamael's suggestion of using systemd, and adding it there from drop-in file or something which survives updates. I didn't understand what you meant by deluge starting before the daemon though, as your reasoning for not using that, as you don't start the UI automatically, atleast not usually.
Last, your reasoning for logging, was to overcome and detect proxy issues, but I'd instead highly suggest installing ltconfig plugin and enabling force_proxy and anonymous_mode, which are available natively in deluge2. This will stop all connections if not going through the defined proxy(and scrub other identifying info away from packets sent) so effectively a kill-switch for proxies. The most important of these, force_proxy, was deprecated and instead used now as default behavior in libtorrent 1.2.x, but deluge 1.3.15 doesn't support over 1.1.x, but not an issue if using ltconfig as stated.
Re: How to pass logging cmd line args to deluged in thin client mode
mhertz, thanks for all this!
Great idea about PATH. I put /usr/bin/deluged back the way it was and moved my deluged script with the logging args into my user bin dir which was already at the front of PATH. Still works fine and it's safe from updates now.
Going back many years, before I had the client-server setup and even before switching to Deluge, I've had my desktop GUI start automatically and then the torrent UI start automatically too. Somehow deluge UI was starting before the daemon, so I enabled the deluge config option to "Automatically start localhost if needed" instead of using systemd. As I mentioned, I was forced to switch to client-server in order to get SickBeard to be able to pass torrents to deluge. I suppose I could try putting an override script in my user bin for deluge, and have it sleep for some number of seconds to allow the daemon to finish starting up, and go back to using systemd. I'm not sure that it would be an improvement though.
So back to the main issue, the proxy business. I didn't know about the ltconfig plugin. I think that's the answer I was looking for. THANKS! I installed it and enabled force_proxy. I'm really vague on trackers and have no idea if they go through proxies, so I was afraid to enable anonymous_mode thinking that some or all of my downloads would fail to start.
To test force_proxy I left my homemade kill switch in place but commented out the "exec deluge-console pause *" command. Then I changed the IP address in the deluge proxy settings to a bogus address (changed 184... to 84...). Transferring slows to a stop and watching from another test machine downloading the same torrents I can see my server drop off its Peers list. IPstatusbar doesn't detect the IP changing, which seems reasonable. When I put the proper proxy IP back into Deluge, everything starts up again. So, SUCCESS!
Thank-you so much!
Great idea about PATH. I put /usr/bin/deluged back the way it was and moved my deluged script with the logging args into my user bin dir which was already at the front of PATH. Still works fine and it's safe from updates now.
Going back many years, before I had the client-server setup and even before switching to Deluge, I've had my desktop GUI start automatically and then the torrent UI start automatically too. Somehow deluge UI was starting before the daemon, so I enabled the deluge config option to "Automatically start localhost if needed" instead of using systemd. As I mentioned, I was forced to switch to client-server in order to get SickBeard to be able to pass torrents to deluge. I suppose I could try putting an override script in my user bin for deluge, and have it sleep for some number of seconds to allow the daemon to finish starting up, and go back to using systemd. I'm not sure that it would be an improvement though.
So back to the main issue, the proxy business. I didn't know about the ltconfig plugin. I think that's the answer I was looking for. THANKS! I installed it and enabled force_proxy. I'm really vague on trackers and have no idea if they go through proxies, so I was afraid to enable anonymous_mode thinking that some or all of my downloads would fail to start.
To test force_proxy I left my homemade kill switch in place but commented out the "exec deluge-console pause *" command. Then I changed the IP address in the deluge proxy settings to a bogus address (changed 184... to 84...). Transferring slows to a stop and watching from another test machine downloading the same torrents I can see my server drop off its Peers list. IPstatusbar doesn't detect the IP changing, which seems reasonable. When I put the proper proxy IP back into Deluge, everything starts up again. So, SUCCESS!
Thank-you so much!
Re: How to pass logging cmd line args to deluged in thin client mode
You're most welcome of-course! Glad to hear you've got things sorted out! OK, then I understand what you meant with your systemd issue. I'm sure you could fix that too e.g add directive to let it start before xorg, or alike but no need to switch to systemd if having an already working setup e.g I neither use systemd for starting deluged, and instead just have it start by a script I made whenever selecting magnet or torrent in web browser and shut it down little after not needed anymore, as little OCD about not wasting cpu/ram on unneeded stuff when possible 
Personally I'd suggest enabling anonymous_mode as there are a few protocol-related leaking IP issues, that potentially could be an issue, although as said force_proxy is the most important by far. Yes, trackers go through proxies too. I don't think there's any downsides to that option. Actually the single anonymous_mode option of much older libtorrents, where only split into two options anonymous_mode/force_proxy, so that anonymous_mode could also be used for VPNs also, which makes sence, though IP cannot be potentially leaked in packet data there, but will scrub other potential identification stuff like clientid, port, user-agent and such. Imho, that's not really that important for VPNs, as no potential issue of IP field of real connection sent correctly over the proxy, but doesn't hurt neither and as said, is recommended for proxies if wanna be optimally safe atleast. I used it myself both before when using proxies, and also currently using VPNs, just not force_proxy of-course as not using proxy anymore and so would stop all connections.
Personally I'd suggest enabling anonymous_mode as there are a few protocol-related leaking IP issues, that potentially could be an issue, although as said force_proxy is the most important by far. Yes, trackers go through proxies too. I don't think there's any downsides to that option. Actually the single anonymous_mode option of much older libtorrents, where only split into two options anonymous_mode/force_proxy, so that anonymous_mode could also be used for VPNs also, which makes sence, though IP cannot be potentially leaked in packet data there, but will scrub other potential identification stuff like clientid, port, user-agent and such. Imho, that's not really that important for VPNs, as no potential issue of IP field of real connection sent correctly over the proxy, but doesn't hurt neither and as said, is recommended for proxies if wanna be optimally safe atleast. I used it myself both before when using proxies, and also currently using VPNs, just not force_proxy of-course as not using proxy anymore and so would stop all connections.
Re: How to pass logging cmd line args to deluged in thin client mode
OK, I enabled anonymous_mode just now. I use SickChill so it should be obvious if some downloads don't happen.
In a Torguard forum I'm told that using ones ISP DNS can cause leaks which in turn result in copyright letters from ISP. That surprises me but I've seen this claim/advice elsewhere as well so just now I switched to the google DNS servers 8.8.8.8 and 8.8.4.4. I do this just on my server, not the router so the rest of the hose isn't affected. Ping shows about 10 ms to the ISP DNS and about 30 to the google server. I doubt I'll notice that.
When I'm away from home I often manually add torrents having looked up a show and getting a torrent or magnet URL and adding it to deluge remotely using the Android app "transdrone". I don't know if this DNS/web activity exposes me or not.
In a Torguard forum I'm told that using ones ISP DNS can cause leaks which in turn result in copyright letters from ISP. That surprises me but I've seen this claim/advice elsewhere as well so just now I switched to the google DNS servers 8.8.8.8 and 8.8.4.4. I do this just on my server, not the router so the rest of the hose isn't affected. Ping shows about 10 ms to the ISP DNS and about 30 to the google server. I doubt I'll notice that.
When I'm away from home I often manually add torrents having looked up a show and getting a torrent or magnet URL and adding it to deluge remotely using the Android app "transdrone". I don't know if this DNS/web activity exposes me or not.
Re: How to pass logging cmd line args to deluged in thin client mode
Yeah, I change to Google DNS's too, despite slower ping than ISP, like you.
People think they need to hide from ISPs because it's them that send you the letters, but in reality it's not them to hide for, as they simply forward letters, so it's the swarm to hide for as includes copyright-agencies logging IPs of infringing users and contacts your ISP.
Still though, it never hurts to be little paranoid regardless so I by rule only use https tracker sites. Granted the ISP will still see the main URL address, as does your DNS provider, but rest of URL, isn't shown to neither of these for https as rest only sent after negotiating the encrypted stream, meaning they can see you e.g visit TPB, but not what you're trying to download from there, or just browsing or whatever. Note, I checked there are linux ISOs on TPB, so visiting that page for instance isn't incriminating, when having nothing else to go by. If using VPN then this wouldn't be an issue though neither, but again this shouldn't really be needed, but why not, as cost you nothing to take these extra easy precautions regardless.
Sorry, I don't know about transdrone and such. Personally I wouldn't worry about it, as said you only specifically need to hide from swarm, but I quickly looked up its using the RPC interface, which I believe is encrypted, though still is recommended to tunnel through e.g SSH or something when connection through internet, I read once on deluge support site or FAQ or alike(not about transdrone specifically, and just about RPC interface and thinclient). That is for security issues I'm guessing and not regarding anything else, plus as said, unrelated to swarm. There is a SSL option in transdrone to encrypt connection, if paranoid.
People think they need to hide from ISPs because it's them that send you the letters, but in reality it's not them to hide for, as they simply forward letters, so it's the swarm to hide for as includes copyright-agencies logging IPs of infringing users and contacts your ISP.
Still though, it never hurts to be little paranoid regardless so I by rule only use https tracker sites. Granted the ISP will still see the main URL address, as does your DNS provider, but rest of URL, isn't shown to neither of these for https as rest only sent after negotiating the encrypted stream, meaning they can see you e.g visit TPB, but not what you're trying to download from there, or just browsing or whatever. Note, I checked there are linux ISOs on TPB, so visiting that page for instance isn't incriminating, when having nothing else to go by. If using VPN then this wouldn't be an issue though neither, but again this shouldn't really be needed, but why not, as cost you nothing to take these extra easy precautions regardless.
Sorry, I don't know about transdrone and such. Personally I wouldn't worry about it, as said you only specifically need to hide from swarm, but I quickly looked up its using the RPC interface, which I believe is encrypted, though still is recommended to tunnel through e.g SSH or something when connection through internet, I read once on deluge support site or FAQ or alike(not about transdrone specifically, and just about RPC interface and thinclient). That is for security issues I'm guessing and not regarding anything else, plus as said, unrelated to swarm. There is a SSL option in transdrone to encrypt connection, if paranoid.
Re: How to pass logging cmd line args to deluged in thin client mode
Thanks to mhertz for the solution to adding logging arguments to deluged:
"Add a shell-script named deluged to be placed in your user bin dir and have that dir added to PATH as in the beginning of PATH so takes precedence (done by most already) and then in that file specify full path to deluged, logging and "$@"."
"Add a shell-script named deluged to be placed in your user bin dir and have that dir added to PATH as in the beginning of PATH so takes precedence (done by most already) and then in that file specify full path to deluged, logging and "$@"."