Need some help troubleshooting deluged connections

[kingram]

I had a linux server running Debian buster
I was running Deluge 1.3 with ease and connecting to deluged with no problems using a python script.
I rebuilt the server with Ubunutu Server 24.04 and can only use the latest Deluge, 2.1.1, since Python 2.7 is EOL.

I installed deluge with APT

Code: Select all

$ apt list *deluge*
Listing... Done
deluge-common/noble,now 2.1.2~dev0+20240121-1 all [installed]
deluge-console/noble,now 2.1.2~dev0+20240121-1 all [installed]
deluge-gtk/noble,now 2.1.2~dev0+20240121-1 all [installed]
deluge-web/noble,now 2.1.2~dev0+20240121-1 all [installed]
deluge/noble,now 2.1.2~dev0+20240121-1 all [installed]
deluged/noble,now 2.1.2~dev0+20240121-1 all [installed]

Deluged is running

Code: Select all

$ sudo service deluged status
● deluged.service - Deluge Bittorrent Client Daemon
     Loaded: loaded (/usr/lib/systemd/system/deluged.service; enabled; preset: enabled)
     Active: active (running) since Thu 2024-11-21 17:34:09 PST; 1min 17s ago
       Docs: man:deluged
   Main PID: 4043901 (deluged)
      Tasks: 4 (limit: 18961)
     Memory: 40.1M (peak: 40.5M)
        CPU: 646ms
     CGroup: /system.slice/deluged.service
             └─4043901 /usr/bin/python3 /usr/bin/deluged -d -c /var/lib/deluged/config -l /var/log/deluged/daemon.log -L info

Nov 21 17:34:09 apollo systemd[1]: Started deluged.service - Deluge Bittorrent Client Daemon.

Deluged is LISTENING on several ports

Code: Select all

$ sudo lsof -i -P -n | grep LISTEN
\\...
deluged   4043901  debian-deluged   10u  IPv4 167350332      0t0  TCP 127.0.0.1:61290 (LISTEN)
deluged   4043901  debian-deluged   13u  IPv4 167350335      0t0  TCP 192.168.xx.xx:61290 (LISTEN)
deluged   4043901  debian-deluged   16u  IPv4 167350338      0t0  TCP 10.5.xx.xx:61290 (LISTEN)
deluged   4043901  debian-deluged   18u  IPv4 167350341      0t0  TCP 10.1.xx.xx:61290 (LISTEN)
deluged   4043901  debian-deluged   20u  IPv4 167350344      0t0  TCP 172.xx.xx.xx:61290 (LISTEN)
deluged   4043901  debian-deluged   22u  IPv4 167350347      0t0  TCP 172.xx.xx.xx:61290 (LISTEN)
deluged   4043901  debian-deluged   34u  IPv4 167349278      0t0  TCP *:58846 (LISTEN)
\\...

I changed `/var/lib/deluged/config/hostlist.conf`and restarted deluged

Code: Select all

{
    "file": 3,
    "format": 1
}{
    "hosts": [
        [
            "901a392a47e546018a41a36cd0566c7b",
            "127.0.0.1",
            62190,
            "localclient",
            "password"
        ],
        [
            "cc77f2701cf34213954cb41dca6d06d7",
            "localhost",
            62190,
            "user",
            "password"
        ]
    ]
}

When I run deluge-console it defaults to port 58846, even though I changed the config to 62190.

Code: Select all

$ deluge-console "config allow_remote"
Could not connect to daemon: 127.0.0.1:58846
 Password does not match
<Deferred at 0x7dfae8774f20 current result: None>

I'm at my wits end here. The documentation is not at all informative or helpful with troubleshooting this problem.
I'm fighting in the dark with no hands here.

What's going on with this version?

Code: Select all

$ deluged --version
deluged 2.1.1
Python: 3.12.3
OS: Linux 6.8.0-47-generic

[ambipro]

When you run `deluge-console` by itself...it should bring up a dialog.



You can add and delete hosts as needed.

Running deluge-console yourself is not the same as running it via systemd/service for config directories, it is likely that you _THINK_ the config file is located there when running it as a user it would actually be located in your home directory inside ~/.config/deluge

You shouldn't need to edit the config file directly like this...use the console dialog.

tl;dr You are editing a system service config directory that does not represent what your config directory would be set to when running them in user-mode. Edit the right file or use the dialog in deluge-console.

[kingram]

When you run `deluge-console` by itself...it should bring up a dialog.
You can add and delete hosts as needed.

Running deluge-console yourself is not the same as running it via systemd/service for config directories, it is likely that you _THINK_ the config file is located there when running it as a user it would actually be located in your home directory inside ~/.config/deluge

You shouldn't need to edit the config file directly like this...use the console dialog.

tl;dr You are editing a system service config directory that does not represent what your config directory would be set to when running them in user-mode. Edit the right file or use the dialog in deluge-console.

Great tip, I forgot to add in that I found the local .config/deluge.
So why is there a difference between the LISTEN port for deluged and the HOST definition that I am adding?

I directly edited `~/.config/deluge/auth` and `~/.config/deluge/hostlist.conf`

Code: Select all

localclient:password:10
kingram:password:10

Code: Select all

{
    "file": 3,
    "format": 1
}{
    "hosts": [
        [
            "c562604ad30b4d099b580526204f9e9d",
            "localhost",
            61290,
            "kingram",
            "password"
        ]
    ]
}

and deluge-console still fails to connect to deluged



And when I attempt to add a host I get an incomprehensible error:




The fundamental issue is less about deluge-console and more about the fact that I cannot get a connection to the active deluged and there is no guidance on troubleshooting that. The default port does not connect and the port indicated as the LISTEN port is `offline`.

What the f*** is going on here? I can understand if I missed something but I can't tell if I missed something there is nothing in the documentation to help me past this point.

[ambipro]

I'm not sure I understand your question at the end of your post, when you say "host definition" - are you referring to what you see in deluge-console where the host list is (like the screenshot I posted)?

Basically, running deluge in any context as a user (not system service) will use the home dir of that user for configuration details.

When you run it as systemd as it seems you are for the daemon itself, it will reference the /var/ path.

This is just the nature of running a system service versus a user-mode process.

The daemon will get its listen port settings from the /var/ path - where as your host list in deluge-console ran as a user will look in the .config path in your home directory of that user.

I'm not sure this answers your question, so if not please clarify what you are asking given what I've just stated if that changes please.

[kingram]

I'm not sure I understand your question at the end of your post, when you say "host definition" - are you referring to what you see in deluge-console where the host list is (like the screenshot I posted)?

Basically, running deluge in any context as a user (not system service) will use the home dir of that user for configuration details.

When you run it as systemd as it seems you are for the daemon itself, it will reference the /var/ path.

This is just the nature of running a system service versus a user-mode process.

The daemon will get its listen port settings from the /var/ path - where as your host list in deluge-console ran as a user will look in the .config path in your home directory of that user.

I'm not sure this answers your question, so if not please clarify what you are asking given what I've just stated if that changes please.

Maybe this can be resolved by focusing on getting a connection to deluged. That seems to be the real difficulty.
deluge-console is just one client instance/example. I actually want to connect through my python script, which I was doing seamlessly with 1.3.

[ambipro]

Honestly, if you're trying to do this via python for a script, I'd suggest maybe you look into using the JSON-RPC end point. I have several scripts I use a class I wrote in python to accomplish a variety of things, and this endpoint is more or less the same as the RPC, and across major version.

Depending on what you're doing, you can find examples on the different branches on my repo https://github.com/zakkarry/deluge-move ... e-mover.py

Otherwise, if you're set on using the RPC for this, I linked you to a client module that autotorrent2 uses for deluge's RPC in another thread.

https://pypi.org/project/deluge-client/

It works well, but will probably require some migration of your script.

If you're looking for a module for the web rather than using my code, there's also https://github.com/jessielw/deluge-web-client which I've helped with a bit.

As far as the deluge-console bug goes, I think this might be related to something @mhertz PR'd a while back, there were some issues with deluge-console. I don't use it personally, so I can't recall. I'll PM him and ask, but IIRC patching it wasn't that big of a deal if this is the same issue.

You've switched from 1.x to 2.x, so expecting things to just work seamlessly in your script is not guaranteed, unfortunately.

The JSON-RPC endpoint has gone more or less unchanged, though, so perhaps if that is a suitable migration to make it may be easier.

[mhertz]

There is some issue with something I see, e.g I'm pretty sure it used to be able to login without password interactively through copying auth and hostlist.conf from e.g /var/lib/deluged/.config/deluge or where ever was, and into ~/.config/deluge, but didn't work for me in quick tests locally. However, merely copying the auth over, still works for non-interactively mode of console-ui(meaning CLI VS TUI) I see.

DjLegolas fixed the port not integer error on dev branch after 2.1.1 released, though should be able to do manually in hostlist.conf, and start deluged again.

Hmm maybe it was only non-localclient account that worked for auto-login when hostlist.conf copied over, need do some tests later as now becoming in doubt honestly, but actually think was like that, and was a check in code for if same account or what I faintly remember, but will run some tests and update later, maybe first in a few days not sure honestly.

As mentioned, ambipro has great code to borrow from, learn and/or get inspired from, so that is always a great resource in and of itself, but could also just post example of what's troubling you, as core python api used from python script do work, e.g I use it myself, for hooking on torrent-finished event, as example.

[kingram]

Honestly, if you're trying to do this via python for a script, I'd suggest maybe you look into using the JSON-RPC end point. I have several scripts I use a class I wrote in python to accomplish a variety of things, and this endpoint is more or less the same as the RPC, and across major version.

Depending on what you're doing, you can find examples on the different branches on my repo https://github.com/zakkarry/deluge-move ... e-mover.py

Otherwise, if you're set on using the RPC for this, I linked you to a client module that autotorrent2 uses for deluge's RPC in another thread.

https://pypi.org/project/deluge-client/

It works well, but will probably require some migration of your script.

If you're looking for a module for the web rather than using my code, there's also https://github.com/jessielw/deluge-web-client which I've helped with a bit.

As far as the deluge-console bug goes, I think this might be related to something @mhertz PR'd a while back, there were some issues with deluge-console. I don't use it personally, so I can't recall. I'll PM him and ask, but IIRC patching it wasn't that big of a deal if this is the same issue.

You've switched from 1.x to 2.x, so expecting things to just work seamlessly in your script is not guaranteed, unfortunately.

The JSON-RPC endpoint has gone more or less unchanged, though, so perhaps if that is a suitable migration to make it may be easier.

I will try RPC this week.

This is my python script:

Code: Select all

import math
import sys
from deluge.ui.client import client
from twisted.internet import reactor

class DelugeInfo:
  
  def __init__(self):
    self.records = []
    self.categories = []
    self.torrents_status = []

    try:
      d = client.connect()
      d.addCallback(self.on_connect_successful)
      d.addErrback(self.on_connect_fail)
      reactor.run()
    except Exception as e:
      self.logError("Error: " + str(e))


  def on_get_torrents_status(self, torrents_status):
    self.torrents_status = torrents_status
    client.disconnect()
    reactor.stop()

  def on_connect_successful(self, result):
    print("Connection Successful")
    client.core.get_torrents_status("", "").addCallback(self.on_get_torrents_status)

  def on_connect_fail(self, result):
    print("Connection Failed!")

  def writeOutput(self):
    print("Write Output")

  def logError(self, text):
    print("Line 38: " + text + "\n")

def main():
  delugeInfo = DelugeInfo()
  # delugeInfo.writeOutput()

if __name__ == '__main__':
  main()
  sys.exit()

Connection fails I think because I cannot connect to deluge daemon.

[mhertz]

Your script works fine, you just need configure the client.connect() call properly, as default values("locahlhost",58846) not what you want, but has defined. Change it to e.g(or whatever your values was):

Code: Select all

      d = client.connect("192.168.0.4",62190,"test","test")

[mhertz]

Sorry slightly off-topic, but maybe could help other users maybe. Anyway, to be honest I never got the idea of the deluge-client project, as always just thought why not just use main python api(rpc api), when using python anyway, but now looking slightly into it, I think it's great as offers two pros imho i.e. it's great for windows, where the rpc api freezed so unusable there for us, whereas 'nix and mac have it already available to use, as included with the deluge install - well obviously can install deluge from pip on windows, to make use off the api there, but deluge-client is then much more lightweight. Second, it's slightly easier since omits the need for using twisted callBacks/errBacks, and so if having simple needs, as pretty lightweight and not includes everything, e.g. I couldn't use as no events, then fine choice indeed. Of-course then also the json-rpc api available for windows users, or when not using python, or simply if just preffered in general of-course(json-rpc wraps the python rpc api in web/json wrapper, and includes own functions for web-UI only). Note when talking rpc api, I don't mean the rpc protocol which is highly complex, atleast for me, but rather the much more user-friendly api for the rpc.

Sorry just wanted off my chest, or how put