deluge.service wont open daemon port after service restart

[bradb19]

I am running deluged 2.1.1 / libtorrent 2.0.5 on Ubuntu Server22.04. After a reboot deluge works perfectly. If I stop the systemd deluged service and then start it again, the daemon port will not open. I am no longer able to connect with the windows thin client

While deluged is running after reboot...

Code: Select all

brad@torrentsvr01:~$ sudo ss -tulpn | grep deluge
[sudo] password for brad:
udp   UNCONN 0      0                    0.0.0.0:6771       0.0.0.0:*    users:(("deluged",pid=643,fd=20))
udp   UNCONN 0      0                    0.0.0.0:6771       0.0.0.0:*    users:(("deluged",pid=643,fd=19))
udp   UNCONN 0      0      192.168.71.210%enp0s3:59124      0.0.0.0:*    users:(("deluged",pid=643,fd=15))
udp   UNCONN 0      0               127.0.0.1%lo:59124      0.0.0.0:*    users:(("deluged",pid=643,fd=13))
udp   UNCONN 0      0             192.168.71.210:1900       0.0.0.0:*    users:(("deluged",pid=643,fd=17))
udp   UNCONN 0      0             192.168.71.210:36982      0.0.0.0:*    users:(("deluged",pid=643,fd=18))
udp   UNCONN 0      0             192.168.71.210:56495      0.0.0.0:*    users:(("deluged",pid=643,fd=16))
tcp   LISTEN 0      50                   0.0.0.0:58846      0.0.0.0:*    users:(("deluged",pid=643,fd=22))
tcp   LISTEN 0      5      192.168.71.210%enp0s3:59124      0.0.0.0:*    users:(("deluged",pid=643,fd=14))
tcp   LISTEN 0      5               127.0.0.1%lo:59124      0.0.0.0:*    users:(("deluged",pid=643,fd=12))

If I stop deluged.service and then restart it tcp 58846 is no longer open...

Code: Select all

brad@torrentsvr01:~$ sudo systemctl stop deluged
brad@torrentsvr01:~$ sudo systemctl start deluged
brad@torrentsvr01:~$ sudo ss -tulpn | grep deluge
udp   UNCONN 0      0                    0.0.0.0:6771       0.0.0.0:*    users:(("deluged",pid=1465,fd=19))
udp   UNCONN 0      0                    0.0.0.0:6771       0.0.0.0:*    users:(("deluged",pid=1465,fd=18))
udp   UNCONN 1280   0      192.168.71.210%enp0s3:59124      0.0.0.0:*    users:(("deluged",pid=1465,fd=14))
udp   UNCONN 0      0               127.0.0.1%lo:59124      0.0.0.0:*    users:(("deluged",pid=1465,fd=12))
udp   UNCONN 28288  0             192.168.71.210:1900       0.0.0.0:*    users:(("deluged",pid=1465,fd=16))
udp   UNCONN 36992  0             192.168.71.210:37057      0.0.0.0:*    users:(("deluged",pid=1465,fd=17))
udp   UNCONN 768    0             192.168.71.210:42422      0.0.0.0:*    users:(("deluged",pid=1465,fd=15))
tcp   LISTEN 0      5      192.168.71.210%enp0s3:59124      0.0.0.0:*    users:(("deluged",pid=1465,fd=13))
tcp   LISTEN 0      5               127.0.0.1%lo:59124      0.0.0.0:*    users:(("deluged",pid=1465,fd=10))

Service unit...

Code: Select all

[Unit]
Description=Deluge Bittorrent Client Daemon
Documentation=man:deluged
After=network-online.target

[Service]
Type=simple
UMask=007
User=deluge
Group=deluge

ExecStart=/usr/bin/deluged -d -l /var/log/deluge/daemon.log -L debug --logrotate

Restart=on-failure

# Time to wait before forcefully stopped.
TimeoutStopSec=300

[Install]
WantedBy=multi-user.target

Core.conf...

Code: Select all

{
    "file": 1,
    "format": 1
}{
    "add_paused": false,
    "allow_remote": true,
    "auto_manage_prefer_seeds": false,
    "auto_managed": true,
    "cache_expiry": 60,
    "cache_size": 512,
    "copy_torrent_file": false,
    "daemon_port": 58846,
    "del_copy_torrent_file": false,
    "dht": true,
    "dont_count_slow_torrents": false,
    "download_location": "/media/sf_MediaShare/Download",
    "download_location_paths_list": [
        "/media/sf_MediaShare/Download"
    ],
    "enabled_plugins": [],
    "enc_in_policy": 1,
    "enc_level": 2,
    "enc_out_policy": 1,
    "geoip_db_location": "/usr/share/GeoIP/GeoIP.dat",
    "ignore_limits_on_local_network": true,
    "info_sent": 0.0,
    "listen_interface": "",
    "listen_ports": [
        6881,
        6881
    ],
    "listen_random_port": 59124,
    "listen_reuse_port": true,
        "listen_use_sys_port": false,
    "lsd": true,
    "max_active_downloading": 3,
    "max_active_limit": 8,
    "max_active_seeding": 5,
    "max_connections_global": 200,
    "max_connections_per_second": 20,
    "max_connections_per_torrent": -1,
    "max_download_speed": -1.0,
    "max_download_speed_per_torrent": -1,
    "max_half_open_connections": 20,
    "max_upload_slots_global": 4,
    "max_upload_slots_per_torrent": -1,
    "max_upload_speed": -1.0,
    "max_upload_speed_per_torrent": -1,
    "move_completed": true,
    "move_completed_path": "/media/sf_MediaShare/Completed",
    "move_completed_paths_list": [],
    "natpmp": true,
    "new_release_check": false,
    "outgoing_interface": "",
    "outgoing_ports": [
        0,
        0
    ],
    "path_chooser_accelerator_string": "Tab",
    "path_chooser_auto_complete_enabled": true,
    "path_chooser_max_popup_rows": 20,
    "path_chooser_show_chooser_button_on_localhost": true,
    "path_chooser_show_hidden_files": false,
    "path_chooser_show_path_entry": true,
    "peer_tos": "0x00",
    "plugins_location": "/home/deluge/.config/deluge/plugins",
    "pre_allocate_storage": false,
    "prioritize_first_last_pieces": false,
    "proxy": {
        "anonymous_mode": false,
        "force_proxy": false,
        "hostname": "",
        "password": "",
        "port": 8080,
        "proxy_hostnames": true,
        "proxy_peer_connections": true,
        "proxy_tracker_connections": true,
        "type": 0,
        "username": ""
    },
    "queue_new_to_top": false,
    "random_outgoing_ports": true,
    "random_port": true,
    "rate_limit_ip_overhead": true,
    "remove_seed_at_ratio": false,
    "seed_time_limit": 180,
    "seed_time_ratio_limit": 7.0,
    "send_info": false,
    "sequential_download": false,
    "share_ratio_limit": 2.0,
    "shared": false,
    "stop_seed_at_ratio": false,
    "stop_seed_ratio": 2.0,
    "super_seeding": false,
    "torrentfiles_location": "/home/deluge/Downloads",
    "upnp": true,
    "utpex": true

This is all I get from daemon.log. It does not show any indication that the service was stopped first. I only see the start. After stopping the daemon, I have checked that there is no deluged process running.

Code: Select all

10:00:24 [INFO    ][deluge.core.daemon            :91  ] Deluge daemon 2.1.1
10:00:24 [DEBUG   ][deluge.core.core              :117 ] Starting session (peer_id: -DE211s-, user_agent: Deluge/2.1.1 libtorrent/2.0.5.0)
10:00:24 [DEBUG   ][deluge.core.core              :327 ] Opening session.state for load: /home/deluge/.config/deluge/session.state
10:00:24 [INFO    ][deluge.core.core              :334 ] Successfully loaded session.state: /home/deluge/.config/deluge/session.state
10:00:24 [DEBUG   ][deluge.core.core              :327 ] Opening session.state for load: /home/deluge/.config/deluge/session.state.bak
10:00:24 [INFO    ][deluge.core.core              :334 ] Successfully loaded session.state: /home/deluge/.config/deluge/session.state.bak

Any ideas where I should go with this? Not sure what to check next.

Thanks
Brad

[mhertz]

Check what the faulty run states in 'systemctl status deluged'.

I would check if systemd related or not, by testing also without systemd e.g 'sudo -u deluge deluged' and 'sudo -u deluge deluge-console halt' to stop, or just 'sudo pkill deluged'.

I was thinking if that timeoutstopsec was related I.e if closing hung, then next start be faulty and need wait, but far fetched, plus you stated deluged not there, plus default wait anyway 120 secs or something, I believe, but indeed sounds like it's hung still. Try after stopping deluged with systemd just anyway run 'sudo pkill -9 deluged' and then start deluged with systemd.

Edit: Sorry the deluge user should be deluged instead(in above 'sudo -u deluge' part of commands), from your output. You have though deluge defined in service, though probably an override systemd file in place, changing that to deluged. I was thinking if was related, but sounds strange if should first be problematic upon second time around(after reboot), but who knows - can check if have override file with e.g 'systemctl cat deluged'.

[shinger]

Hello Brad,

I am going to wait with the outcome of mhertz. Could you also do a

grep on port 58846 to be sure if no other applications have hijacked this port instead?

If no applications are using it , try to change to a different port and see how that goes.

[bradb19]

mhertz....

output status...

Code: Select all

brad@torrentsvr01:~$ sudo systemctl status deluged
● deluged.service - Deluge Bittorrent Client Daemon
     Loaded: loaded (/etc/systemd/system/deluged.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2023-10-20 11:44:01 EDT; 3h 57min ago
       Docs: man:deluged
   Main PID: 655 (deluged)
      Tasks: 3 (limit: 4557)
     Memory: 53.8M
        CPU: 540ms
     CGroup: /system.slice/deluged.service
             └─655 /usr/bin/python3 /usr/bin/deluged -d -l /var/log/deluge/daemon.log -L info --logrotate

Oct 20 11:44:01 torrentsvr01.bender.int systemd[1]: Started Deluge Bittorrent Client Daemon.

Output from ss after stopping deluged.service and also after pkill -9 deluged (same result both times)....

Code: Select all

brad@torrentsvr01:~$ sudo ss -tulpn
Netid  State   Recv-Q   Send-Q     Local Address:Port      Peer Address:Port  Process
udp    UNCONN  0        0                0.0.0.0:10000          0.0.0.0:*      users:(("miniserv.pl",pid=1023,fd=6))
udp    UNCONN  0        0          127.0.0.53%lo:53             0.0.0.0:*      users:(("systemd-resolve",pid=636,fd=13))
tcp    LISTEN  0        4096             0.0.0.0:10000          0.0.0.0:*      users:(("miniserv.pl",pid=1023,fd=5))
tcp    LISTEN  0        4096       127.0.0.53%lo:53             0.0.0.0:*      users:(("systemd-resolve",pid=636,fd=14))
tcp    LISTEN  0        128              0.0.0.0:22             0.0.0.0:*      users:(("sshd",pid=721,fd=3))
tcp    LISTEN  0        511                    *:80                   *:*      users:(("apache2",pid=727,fd=4),("apache2",pid=726,fd=4),("apache2",pid=725,fd=4))
tcp    LISTEN  0        128                 [::]:22                [::]:*      users:(("sshd",pid=721,fd=4))

There is no override on the systemd file. deluge is the user running the deluged daemon.
I ran deluged like this but 58846 still not open...

Code: Select all

 
brad@torrentsvr01:~$ sudo -u deluge deluged
brad@torrentsvr01:~$ sudo ss -tulpn | grep deluge
udp   UNCONN 36992  0             192.168.71.210:36001      0.0.0.0:*    users:(("deluged",pid=1423,fd=17))
udp   UNCONN 768    0             192.168.71.210:56766      0.0.0.0:*    users:(("deluged",pid=1423,fd=15))
udp   UNCONN 0      0      192.168.71.210%enp0s3:59124      0.0.0.0:*    users:(("deluged",pid=1423,fd=14))
udp   UNCONN 0      0               127.0.0.1%lo:59124      0.0.0.0:*    users:(("deluged",pid=1423,fd=12))
udp   UNCONN 32640  0             192.168.71.210:1900       0.0.0.0:*    users:(("deluged",pid=1423,fd=16))
udp   UNCONN 0      0                    0.0.0.0:6771       0.0.0.0:*    users:(("deluged",pid=1423,fd=19))
udp   UNCONN 0      0                    0.0.0.0:6771       0.0.0.0:*    users:(("deluged",pid=1423,fd=18))
tcp   LISTEN 0      5      192.168.71.210%enp0s3:59124      0.0.0.0:*    users:(("deluged",pid=1423,fd=13))
tcp   LISTEN 0      5               127.0.0.1%lo:59124      0.0.0.0:*    users:(("deluged",pid=1423,fd=10))

I have never used "sudo -u deluge deluge-console halt" before but I believe its not working because it can't connect to the daemon on 58846. The port is not open. I used pkill instead.

I changed the timeout from 300 to 120. I find it interesting that the daemon log makes no mention of stopping the service. Normally if you stop deluged would you not get a line in the log? Here is the log file after starting and then stopping deluged.service

Code: Select all

16:00:43 [INFO    ][deluge.core.daemon            :91  ] Deluge daemon 2.1.1
16:00:43 [DEBUG   ][deluge.core.core              :117 ] Starting session (peer_id: -DE211s-, user_agent: Deluge/2.1.1 libtorrent/2.0.5.0)
16:00:43 [DEBUG   ][deluge.core.core              :327 ] Opening session.state for load: /home/deluge/.config/deluge/session.state
16:00:43 [INFO    ][deluge.core.core              :334 ] Successfully loaded session.state: /home/deluge/.config/deluge/session.state
16:00:43 [DEBUG   ][deluge.core.core              :327 ] Opening session.state for load: /home/deluge/.config/deluge/session.state.bak
16:00:43 [INFO    ][deluge.core.core              :334 ] Successfully loaded session.state: /home/deluge/.config/deluge/session.state.bak

Brad

[bradb19]

shinger....

I have been doing the grep on 58846 as well and it does not return anything.

I also tried changing to an arbitrary port (49505) and I'm still getting the same results. Unable to connect to the daemon. The port is not opened.

Brad

[mhertz]

I'm sorry, i'm not very acquainted with ss honestly, so thought "users: deluged....." ment just that, sorry.

So you did ran 'sudo -u deluge deluged' and it still didn't work right, or so I believe("I ran deluge like this..."), so not related to systemd per-say, but why it works at boot and not later I really don't know sorry.

Personally I would try with completely fresh config-dir, so delete old and have it regenerated. Could also try other libtorrent, e.g. from pypi(pip install -U libtorrent), but i'm affraid I have no actual helpful tips to give sadly, other than myself would reinstall deluge, regenerate user, use exact services from deluge docs, change libtorrent version, try deluge from pip instead, try downgrade deluge, use own user, etc etc, just to see where issue lies, to pursue from further. Sorry, hopefully other good people here have some helpful tips to give.

@shinger, Thanks mate, should have thought off that, but glad you're here when not

Edit: Upgrading to libtorrent 2.0.9 helped the last person having this issue, well atleast likeminded issue, and same OS and rest details(every stop, borks profile and hinders next startup): viewtopic.php?t=56523 - temporary-fix was deleting session.state in config-dir, but tedious as continually happened. Probably also other libtorrent than 2.0.9 works, and just the change away from 2.0.5 or whatever have you, was the culprit, for that setup for some reason.

[bradb19]

Now I've determined that deluged will restart properly if I wait about 20 minutes after shutting it down. I tried waiting only 5 or 10 minutes and that will fail every time. Not sure why I'm seeing this behaviour. I will update libtorrent to 2.0.9 and see if that makes a difference.

Brad

[bradb19]

Update:
Problem solved!!! I updated libtorrent from 2.0.5 to 2.0.9 and everything is working as it should. I also set the SSL_CERT_FILE variable you noted. I set the variable right in the unit file for deluged.service

[mhertz]

I'm pretty sure it does - you can also see last update from log is from session.state loaded, and indeed can break deluge starting properly, I completely forgot stupidly(seen it plenty myself, e.g. on windows during testing in older times - I made unofficial installer delete it upon updates because of it).

Easiest probably is something like 'sudo -u deluge pip install -U libtorrent', giving you a libtorrent 2.0.9 only for deluge user, under '/home/deluge/.local/lib/python3.10/system-site-packages/libtorrent' - they removed the 'sudo pip install' option recently in bep668, though can also make venv and install into and source to activate from .bashrc/.zshrc, let me know if need help.

As said, quick test is just deleting session.state* in profile with deluged closed and restart.

Edit: Too late, glad to hear!

Edit2: Bep668 of python(/pip) not on ubuntu 22.04, only 23+ seemingly, plus even prohibits user installs too(like my command above) and so need venv's specifically, or forcing override - just wanted correct myself.

[bradb19]

Thank you for your help. Appreciate it!
Brad