Deluge

per this: https://dev.deluge-torrent.org/wiki/Faq ... enpassword
try stopping the webui service and deleting the pwd_sha1 line in the web.conf file. That should make deluge reset it to the default when the service starts up again.

Sounds like maybe you're using your Gtk client password in the WebUI?

The WebUI has it's own password (set to deluge by default, if I remember), port, and service.

The username/password pair is for logging into the Gtk client.

When I use

the file is moved, but afterward the console hangs and doesn't return until I keyboard interrupt.

Anyone else experience this? Am I doing something wrong?

well done, thank you!

I think my problem was that I was editing core.conf directly while the daemon was running. I guess that's a no-no.

I ran deluge as a user process to generate a fresh config in my home directory, then copied ~/.config/deluge to /etc/deluge and everything seems to work again with the above caveat.

Tried the alternate systemd unit with same results as existing unit. Searched system for core.conf with and only found the one in /etc/deluge and the one in /root/.config/deluge/

/var/lib/deluge doesn't exist

I'm running deluge from a systemd unit file in /etc/systemd/system/: [Unit] Description=Deluge Daemon After=network.target [Service] User=deluge ExecStart=/usr/bin/deluged -d -c /etc/deluge UMask=0002 Install] WantedBy=multi-user.target The contents of /etc/deluge are: -rw-rw-r-- 1 deluge deluge 73 ...

Thank you, Cas. I have updated my service config files with:



and after reloading the services, things are working splendidly again. Your advice is much appreciated!

After upgrading to deluge 1.3.12-1 and Arch 4.2.1-1 and restarting my machine, I can't connect to my running daemon anymore. systemctl status deluged: $ systemctl status deluged ● deluged.service - Deluge Daemon Loaded: loaded (/usr/lib/systemd/system/deluged.service; enabled; vendor preset: disable...