Deluge Forum

Running Ubuntu 20.04.6 all updates Deluge 2.1.1
I have about 70 active torrents seeding at all times to keep my ratio up. The only time I can login to the webui remotely and see my seeding torrents are after I RDP to the ubuntu desktop and start deluge through the ubuntu desktop icon with the deluge webui plugin enabled. I've setup the deluged and deluge-web systemd service using the deluge user. When I enable the deluged and deluge-web services and start them before using the manual desktop method, I'm able to connect fine but I don't see any of my 70 torrents seeding after connecting remotely. When I disable the systemd deluge-web service and reboot the machine and manually start deluge again from the desktop with the webui plugin enabled then login remotely all the torrents are showing. I'm not showing any errors in the logs /var/log/deluge etc. Am I missing something? I'm trying to set this up so deluge starts with the OS without having to manually login and click the deluge icon. Any help much appreciated. I have had this VM running deluge for a long time and I think I do remember upgrading from deluge v1x to the 2x but can't remember.

Your systemd process likely is not using the same user and thus config directory as your user, which would have a HOMEDIR set differently.

You can specify the deluged config directory to use with the `-c` parameter and an argument passed for the path. This should result in launching deluged with the loaded torrents.

Furthermore you can enable logging as well if it is not already sufficient with the defaults.

https://man.archlinux.org/man/deluged.1.en for the complete list of deluged CLI commands/args

Your user's config directory should most likely be ~/.config/deluge/ or similiar.

Thank you Thank you! I had a couple of things going on. I changed the user running the daemon to what I wanted in the user.conf. Then I used the -c flag in the .service to specify the config location of the daemon user. I also had to change the permissions (recursively of course) on the /var/log/deluge folder where I was logging in the .service. Now all is happy.
Example of my service
ExecStart=/usr/bin/deluged -d -l /var/log/deluge/daemon.log -L info -c /home/"abovedaemonuser"/.config/deluge

Great, seen this before so knew what the likely cause was.

Glad to help

Hi all.

Sorry to "steal the thread" ...

I have experienced the same and it is a pain in the b....
I really think the Deluge installation shoudn't make this service setup.
The user should do that manually after the installation.

The above is just my suggestion, but ...

The issue is not the service itself, it is performing as intended. You just can't switch between service and regular user mode arbitrarily and expect the same configuration to be used.

This same issue would be present if you su'd to another user on the system and ran Deluge as well.

Deluge and Linux do not operate on global users/profiles....Windows does not do this either.

I'm unaware of the reason the service why Deluge is at fault here, it's merely a permissions/user configuration flaw that the user needs to address.

The service is okay "per se", it just shouldn't autostart under it's own named user.
When I switch from standard Deluge to "Deluge Thin Client" the service starts up on its own.
The result is, that you are not able to connect without doing some lengthily changes.

I am not a savy in Linux so this behavior i most unwanted.
I am running Ubuntu 24.04 and I haven't figured out to stop the Autostart.
It is working differently than earlier Ubuntu versions (22.04 and earlier).
I have to do a pkill and then start Deluge

I'm not 100% sure of this, but switching to thin client should not affect the startup of a system service.

It is not implied by simply switching to thin client that you would want to run the daemon on your current machine, and this behavior does not translate to window so I'd be hesitant to say that it would do so on Ubuntu, if this is happening I'd assume it is not intended.

It has happened to me on all Ubuntu 23.10 and 24.04 versions.
Something different as normal systemd kicks in, when you change behavior to Thin Client.

I haven't found the solution to prevent this from happening, if you have some guide for this I would really appreciate it.

ambipro wrote: ↑Tue Aug 27, 2024 4:13 pm Your systemd process likely is not using the same user and thus config directory as your user, which would have a HOMEDIR set differently.

You can specify the deluged config directory to use with the `-c` parameter and an argument passed for the path. This should result in launching deluged with the loaded torrents.

Furthermore you can enable logging as well if it is not already sufficient with the defaults.

https://man.archlinux.org/man/deluged.1.en for the complete list of deluged CLI commands/args

Your user's config directory should most likely be ~/.config/deluge/ or similiar.

Hey I am relatively new to deluge and a novice in general. I am experiencing a similar problem to op. I had a install of deluge running in docker on an unraid server. Today I logged into my private torrent tracker and noticed that I was no longer seeding or leeching any torrents. I tried to open the deluge webui from unraid like I normally do and it would not connect. I thought this was weird and restarted the container after switching the config path to my cache instead of the array. when I reload the web ui it will now connect but none of my previous torrents are displayed, but when I go to my private tracker it says they are now seeding again. The weird thing is that it says they are seeding from a completely different ip address. This all happened after running a parity check this morning so I'm not sure if that could have had an effect. I don't know if this method you described would help me but I'm not sure how to even perform the fix you described. If you think it would be helpful could you describe in a little more detail how to a perform the command you're describing? Any help you can provide at all would be greatly appreciated!