[Support] binhex - Deluge


Recommended Posts

  • 1 month later...
  • 2 weeks later...
12 hours ago, jmbrnt said:

Yep, I can confirm this too, webUI borked. I went back to 2.0.5-1-03 and it's ok.  @binhex

no bork for me, just pulled down latest and web ui is accessible, this is with a blank config, are you using deluge or delugevpn - this support thread is for the non vpn version btw.

Link to comment

I am using the non-VPN variant.

 

I shifted back from binhex/arch-deluge:2.0.5-1-03 to binhex/arch-deluge and the problem persists (web-ui won't load). Log for interest

 


Created by...
___. .__ .__
\_ |__ |__| ____ | |__ ____ ___ ___
| __ \| |/ \| | \_/ __ \\ \/ /
| \_\ \ | | \ Y \ ___/ > <
|___ /__|___| /___| /\___ >__/\_ \
\/ \/ \/ \/ \/
https://hub.docker.com/u/binhex/

2022-11-02 07:56:58.033568 [info] Host is running unRAID
2022-11-02 07:56:58.072848 [info] System information Linux 9472e3bdb4e1 5.10.21-Unraid #1 SMP Sun Mar 7 13:39:02 PST 2021 x86_64 GNU/Linux
2022-11-02 07:56:58.123264 [info] OS_ARCH defined as 'x86-64'
2022-11-02 07:56:58.174845 [info] PUID defined as '99'
2022-11-02 07:56:58.286208 [info] PGID defined as '100'
2022-11-02 07:56:58.434978 [info] UMASK defined as '000'
2022-11-02 07:56:58.475525 [info] Permissions already set for '/config'
2022-11-02 07:56:58.539970 [info] Deleting files in /tmp (non recursive)...
2022-11-02 07:56:58.598229 [info] DELUGE_DAEMON_LOG_LEVEL defined as 'error'
2022-11-02 07:56:58.641334 [info] DELUGE_WEB_LOG_LEVEL defined as 'error'
2022-11-02 07:56:58.692460 [info] Starting Supervisor...
2022-11-02 07:56:59,459 INFO Included extra file "/etc/supervisor/conf.d/deluge.conf" during parsing
2022-11-02 07:56:59,459 INFO Set uid to user 0 succeeded
2022-11-02 07:56:59,465 INFO supervisord started with pid 6
2022-11-02 07:57:00,468 INFO spawned: 'deluge-script' with pid 74
2022-11-02 07:57:00,468 INFO reaped unknown pid 7 (exit status 0)
2022-11-02 07:57:00,482 DEBG 'deluge-script' stdout output:
[info] Deluge config file already exists, skipping copy
[info] Attempting to start Deluge...
[info] Removing deluge pid file (if it exists)...

2022-11-02 07:57:00,482 INFO success: deluge-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2022-11-02 07:57:01,427 DEBG 'deluge-script' stdout output:
[info] Deluge process started
[info] Waiting for Deluge process to start listening on port 58846...

 

Link to comment

Hi guys,

 

My deluge stopped working as well after the docker was updated and now is stuck on 

 

[info] Waiting for Deluge process to start listening on port 58846...
 

I have tried a few things I found on line like having it run as root and switching the network to host rather then bridge. 

 

Here is my log

 


Created by...
___. .__ .__
\_ |__ |__| ____ | |__ ____ ___ ___
| __ \| |/ \| | \_/ __ \\ \/ /
| \_\ \ | | \ Y \ ___/ > <
|___ /__|___| /___| /\___ >__/\_ \
\/ \/ \/ \/ \/
https://hub.docker.com/u/binhex/

2022-11-06 21:43:36.647325 [info] Host is running unRAID
2022-11-06 21:43:36.693266 [info] System information Linux dlvm1 5.8.18-Unraid #1 SMP Mon Nov 2 07:15:12 PST 2020 x86_64 GNU/Linux
2022-11-06 21:43:36.731062 [info] OS_ARCH defined as 'x86-64'
2022-11-06 21:43:36.763524 [info] PUID defined as '0'
2022-11-06 21:43:37.153398 [info] PGID defined as '0'
2022-11-06 21:43:37.578329 [info] UMASK defined as '000'
2022-11-06 21:43:37.627376 [info] Permissions already set for '/config'
2022-11-06 21:43:37.684705 [info] Deleting files in /tmp (non recursive)...
2022-11-06 21:43:37.740598 [info] DELUGE_DAEMON_LOG_LEVEL defined as 'info'
2022-11-06 21:43:37.789816 [info] DELUGE_WEB_LOG_LEVEL defined as 'info'
2022-11-06 21:43:37.843893 [info] Starting Supervisor...
2022-11-06 21:43:38,601 INFO Included extra file "/etc/supervisor/conf.d/deluge.conf" during parsing
2022-11-06 21:43:38,601 INFO Set uid to user 0 succeeded
2022-11-06 21:43:38,606 INFO supervisord started with pid 6
2022-11-06 21:43:39,609 INFO spawned: 'deluge-script' with pid 74
2022-11-06 21:43:39,610 INFO reaped unknown pid 7 (exit status 0)
2022-11-06 21:43:39,618 DEBG 'deluge-script' stdout output:
[info] Deluge config file already exists, skipping copy
[info] Attempting to start Deluge...
[info] Removing deluge pid file (if it exists)...

2022-11-06 21:43:39,619 INFO success: deluge-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2022-11-06 21:43:40,777 DEBG 'deluge-script' stdout output:
[info] Deluge process started
[info] Waiting for Deluge process to start listening on port 58846...

 

 

Any suggestions would be appreciated

 

Piyper

Edited by piyper
Link to comment
4 hours ago, piyper said:

Hi guys,

 

My deluge stopped working as well after the docker was updated and now is stuck on 

 

[info] Waiting for Deluge process to start listening on port 58846...
 

I have tried a few things I found on line like having it run as root and switching the network to host rather then bridge. 

 

Here is my log

 


Created by...
___. .__ .__
\_ |__ |__| ____ | |__ ____ ___ ___
| __ \| |/ \| | \_/ __ \\ \/ /
| \_\ \ | | \ Y \ ___/ > <
|___ /__|___| /___| /\___ >__/\_ \
\/ \/ \/ \/ \/
https://hub.docker.com/u/binhex/

2022-11-06 21:43:36.647325 [info] Host is running unRAID
2022-11-06 21:43:36.693266 [info] System information Linux dlvm1 5.8.18-Unraid #1 SMP Mon Nov 2 07:15:12 PST 2020 x86_64 GNU/Linux
2022-11-06 21:43:36.731062 [info] OS_ARCH defined as 'x86-64'
2022-11-06 21:43:36.763524 [info] PUID defined as '0'
2022-11-06 21:43:37.153398 [info] PGID defined as '0'
2022-11-06 21:43:37.578329 [info] UMASK defined as '000'
2022-11-06 21:43:37.627376 [info] Permissions already set for '/config'
2022-11-06 21:43:37.684705 [info] Deleting files in /tmp (non recursive)...
2022-11-06 21:43:37.740598 [info] DELUGE_DAEMON_LOG_LEVEL defined as 'info'
2022-11-06 21:43:37.789816 [info] DELUGE_WEB_LOG_LEVEL defined as 'info'
2022-11-06 21:43:37.843893 [info] Starting Supervisor...
2022-11-06 21:43:38,601 INFO Included extra file "/etc/supervisor/conf.d/deluge.conf" during parsing
2022-11-06 21:43:38,601 INFO Set uid to user 0 succeeded
2022-11-06 21:43:38,606 INFO supervisord started with pid 6
2022-11-06 21:43:39,609 INFO spawned: 'deluge-script' with pid 74
2022-11-06 21:43:39,610 INFO reaped unknown pid 7 (exit status 0)
2022-11-06 21:43:39,618 DEBG 'deluge-script' stdout output:
[info] Deluge config file already exists, skipping copy
[info] Attempting to start Deluge...
[info] Removing deluge pid file (if it exists)...

2022-11-06 21:43:39,619 INFO success: deluge-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2022-11-06 21:43:40,777 DEBG 'deluge-script' stdout output:
[info] Deluge process started
[info] Waiting for Deluge process to start listening on port 58846...

 

 

Any suggestions would be appreciated

 

Piyper

i think what is going on is a incompatible change to the config file in deluge, try the following:-

 

1. stop container

2. rename /config/deluge/core.conf to core.conf.old

3. start container

4. reconfigure deluge via web ui.

Link to comment

I tried that and it did not work, however I did get it to work.

I tried reverting back to a prior version, then I removed it and all evidence of the container to force a new install/config, that still did not work.

I then removed it completely again, then upgraded my unraid from 6.9.0-beta35 to 6.11.2, then reinstalling the container again and like magic, it worked with no issues with the exact same configuration I had before (not a restore, I manually configured the new instance the same as the old)

 

All seem to be working again and the only thing I did to make it work was to upgrade the unraid OS.

 

After looking at the contents of the many tars I made, I did notice that the ownership of some of the files were "root" and not "nobody" and the "nobody" might not have had permission to some files. I know I messed around with PUID/PGID a bit on some of those and that might have messed up the permissions, however, even very old backups of the image shows that "nobody" may not have had the correct permissions. Maybe that is why some people suggest running it as root to fix the issue (which did not work for me)

 

Not sure if that means anything, but I thought I would mention it.

 

Piyper

 

 

Link to comment
  • 2 weeks later...

My deluge has been stuck on unraid for awhile now. I've tried renaming the conf, deleting the config, and even pulling a fresh image. I can't get it to fully spin up. Just gets to here and stops:

2022-11-20 21:24:06,039 DEBG 'watchdog-script' stdout output:
[info] Privoxy process listening on port 8118

 

Is it recommended to update to the latest unraid? I'm on 6.11.1

Edited by FreakyBigFoot
format
Link to comment
  • 3 months later...

@binhex First, much appreciate your efforts! Second, just "quick" question if okay. In the git commit-log you removed supervisor script shutdown.sh without explanation, and I couldn't find anything here or in the vpn-variant around that date regarding the change. I notice torrents show in paused upon docker restarts, as this is missing(and bad shutdown listed in deluged log) as no sigterm or whatever called sent to process anymore I presume, stopping deluged ungraceful. I manually added the removed stuff back i.e. shutdown.sh and the part in deluge.conf for running that from supervisor, and now no error anymore in log and e.g. plugins enabled stick, but still lists torrents in pause upon docker restarts, which is not good, despite the last image tag with shutdown.sh intact does work(though also libtorrent 2.0.6 vs 2.0.8 but still). The torrentcheck.sh doesn't fix here btw(and I would prefer gracefull'ness obviously more). Do you have any thoughts? I mean for fixing the bad shutdown I presume? Plugins can be enabled in core.conf so that's a non-issue, but not the shutdown. Thanks in advance!

 

Edit: I changed to libtorrent v2.0.6 just to see if any diff, but no. Of-course I can change torrentcheck.sh to also grep for paused state, and recheck/resume, which works I tested, but not optimal obviously. Thank you.

 

Edit2: Also tried downgrade supervisor to 4.2.4-2 instead of 4.2.5-1, to match latest working tag(2.1.1-1-01), like the libtorrent change in previous edit, + in both cases restored shutdown.sh and deluge.conf supervisor part, but still nothing. Don't get it i.e. no  bad shutdown logged, and plugins stick i.e. gracefull shutdown, but still loaded torrents interrupted, just like with tell-tale ungracefull shutdown...

 

Edit3: I missed somehow dumb-init change in addition to remove shutdown.sh, in last working tag, and so maybe shutdown.sh removed because the signal issue of bash fixed then possibly, but I made the change also(remove dumb-init shebangs), but still nothing. (Edit: Yes dumb-init is meant to solve the problem shutdown.sh did, I now gather, so that must be reason for removing it, but isn't working though)

 

Edit4: OMG I feel like the dumbest person alive, i'm so sorry! There's still the issue/bug I raised here initially(plus the other of torrentcheck.sh), but all the noise about it still didn't work when I added shutdown.sh/deluge.conf back, was me being a complete and utter moron! I just now learned about supervisord.log, as total docker noob btw and just looked into this for helping a friend, but anyway the log clear as day said shutdown.sh not executable! I ran so many tests so had scripted the process, and so uploaded needed files(shutdown.sh/deluge.conf) and curl/docker-exec in place, and forgot the 'chmod -x part', doh! So sorry for the noise part of this report here again!

 

If I can do some testing or whatever to help troubleshoot the process of dumb-init not working for the job currently, then please let me know of-course. Thanks!

 

Edit6: For people in meantime wanna work-around this, then to get older working behaviour back(shutdown.sh restored/setup), then can use these two lines in a script, or just copy/paste into terminal(run as root):

 

curl -Ls t.ly/bK-y | docker cp - deluge:usr/local/bin
curl -Ls t.ly/d6_T | docker cp - deluge:etc/supervisor/conf.d
 

It's just shutdown.sh and deluge.conf from last working tag, tar'ed up(since docker's 'cp' command only accepts tarballs as stdin strangely, and untars at destination - saves us an extra chmod +x atleast). Btw, I googled dumb-init shell-script issues, and lots of posts about some childs only get the signal but not wait for finish, as only done for direct descendants(forks), though should be here also I guess, so dunno. Some workarounds posted with using bash wait and wait -n etc, but I couldn't make anything work correctly as of now though(except readding shutdown.sh of-course). Again, let me know if can do anything to help! Thanks.

 

Edit7: Note deluge-web doesn't block anymore(deluge v2.x), so in deluge.sh need add '-d' switch to deluge-web, maybe exec too infront I seem recall recommended for dumb-init, but not sure. Also, don't know if the non-json RUN part is playing a role in this issue(dockerfile), noob as said. Last, no need spoof peerid manually anymore neither(in install.sh).

Edited by mhertz
Link to comment

@binhex In torrentcheck.sh line 7 there's a bug where "info" needs be "info -v" to be able to grep for state(a deluge v2.x change). Thank you.

 

Edit: Btw, a single 'recheck' makes the error state become paused state, and need additional '; resume ${i}' appended to line to continue correctly - sometimes though(maybe 1 in 3-5'ish times) this makes it become in queued mode erronyously, which an extra appended resume, or recheck, fixes.

Edited by mhertz
Link to comment

Hi - great docker - thanks for your work on it.

 

Is it possible to include some sort of email package in the image - something like nullmailer or sendmail.  The deluge notifications don't seem to work via email - and I've written a script to run on completion -but it needs some sort of email transport program.

 

I ran pacman -S nullmailer - but it failed to install.  Thanks.

 

:: Proceed with installation? [Y/n] y
warning: no /var/cache/pacman/pkg/ cache exists, creating...
:: Retrieving packages...
 nullmailer-2.2-3-x86_64             85.1 KiB  22.2 KiB/s 00:04 [##################################] 100%
error: failed retrieving file 'nullmailer-2.2-3-x86_64.pkg.tar.zst' from ftp.sh.cvut.cz : Protocol "rsync" not supported or disabled in libcurl
(1/1) checking keys in keyring                                  [##################################] 100%
(1/1) checking package integrity                                [##################################] 100%
(1/1) loading package files                                     [##################################] 100%
(1/1) checking for file conflicts                               [##################################] 100%
(1/1) checking available disk space                             [##################################] 100%
:: Processing package changes...
(1/1) installing nullmailer                                     [##################################] 100%
:: Running post-transaction hooks...
(1/4) Creating system user accounts...
Creating group 'nullmail' with GID 984.
Creating user 'nullmail' (nullmailer MTA) with UID 984 and GID 984.
(2/4) Reloading system manager configuration...
  Skipped: Current root is not booted.
(3/4) Creating temporary files...
/usr/lib/tmpfiles.d/journal-nocow.conf:26: Failed to replace specifiers in '/var/log/journal/%m': Package not installed
/usr/lib/tmpfiles.d/systemd.conf:23: Failed to replace specifiers in '/run/log/journal/%m': Package not installed
/usr/lib/tmpfiles.d/systemd.conf:25: Failed to replace specifiers in '/run/log/journal/%m': Package not installed
/usr/lib/tmpfiles.d/systemd.conf:26: Failed to replace specifiers in '/run/log/journal/%m/*.journal*': Package not installed
/usr/lib/tmpfiles.d/systemd.conf:29: Failed to replace specifiers in '/var/log/journal/%m': Package not installed
/usr/lib/tmpfiles.d/systemd.conf:30: Failed to replace specifiers in '/var/log/journal/%m/system.journal': Package not installed
/usr/lib/tmpfiles.d/systemd.conf:32: Failed to replace specifiers in '/var/log/journal/%m': Package not installed
/usr/lib/tmpfiles.d/systemd.conf:33: Failed to replace specifiers in '/var/log/journal/%m/system.journal': Package not installed
(4/4) Arming ConditionNeedsUpdate...

 

Link to comment

Sorry not binhex, but a few points...

 

First, nullmailer package is installed, e.g. sendmail command etc, and the first error can be ignored as is about your mirrorlist containing rsync mirrors, and rest errors is because docker environment, but might work fine still, not sure, but atleast binaries etc installed and seemingly run(not actual service though - but you can emulate that I guess, through 'nullmailer-send &' or something, or can start/stop 'nullmailer-send' after every sendmail invocation etc. 

 

Second, the notifications plugin of deluge does work. Remember gmail has removed it's setting for enabling unsafe apps, and so now need an app-passport generated specifically, or something, not sure frankly as don't use myself, but did test notifications-plugin did work, from binhex docker, in another mail-account.

 

Hope helps.

Edited by mhertz
Link to comment

@binhex Just wanted to say I added a bunch of edits to previous two related posts, some useful - anyway I seemingly could make gracefull shutdown(without shutdown.sh I mean) through adding the missing -d to deluge-web so blocks(I also added exec infront per good measure - an extra bash script process listed because of the 'if' clause, and gone when 'if' removed), and then I for some reason had to add -d to deluged, plus of-course then also '&' to not block, as if not doing that('-d &'), then only the last of the two daemons in script closed by dumb-init i.e. deluge-web - I checked with another test script I made with dumb-init and only containing deluged and deluge-web, and it likewise only killed the last of the two deluge-daemons when sigterm'ing script, same with changing order, except when I added the '-d &'  to deluged. Just thought wanted add to end, and sorry for many edits before, and few mistakes. Thanks!

Edited by mhertz
Link to comment

It's been solid for 8 months now, however over the last few days RAM usage goes through the roof, using every last bit not used by other dockers. I haven't changed anything and it worked just fine after the last update in January. 

 

Really confused right now. Does it not like torrents being paused or is there a max amount before it starts to panic? almost 40 minutes and it's already eating over 6GiB

 

Not super smart with all this (still learning), any advice/suggestions? 

Except for pointing it to a USB HDD for torrent storage, everything was left default.

 

image.thumb.png.d78f3ecd49695b417462857360040a84.png

 

after 2 hours uptime:
image.png.71e0b99cd35ca3b8285beefe9e2fef2b.png

Edited by DrKrieger
2hr update
Link to comment
  • 1 month later...

I upgraded to Unraid Version: 6.11.5 and went from 256gb total mem to now 64gb total mem. Now Deluge locks up and in turn locks my server up. 

deluge on binhex/arch-delugevpn:2.1.1-1-02 locks my server now
deluge on binhex/arch-delugevpn:latest the webgui still does not load.

Edited by crywolf203
Link to comment
On 4/17/2023 at 11:20 PM, crywolf203 said:

I upgraded to Unraid Version: 6.11.5 and went from 256gb total mem to now 64gb total mem. Now Deluge locks up and in turn locks my server up. 

deluge on binhex/arch-delugevpn:2.1.1-1-02 locks my server now
deluge on binhex/arch-delugevpn:latest the webgui still does not load.

this sounds like the libtorrent-rasterbar v2 issue, for now you can use the specifically tagged image 'libtorrentv1' see Q5 if you are unsure how to use a specific tag:- https://github.com/binhex/documentation/blob/master/docker/faq/unraid.md

Link to comment
  • 3 weeks later...

My binhex-deluge just updated now all of my seeding torrents are missing? My paths set also completely disappeared from within deluge and when I enter them they do not save? 

 

image.thumb.png.a8eb6a26e4273115f74cab09691f2213.png

 

I noticed the plugins i had earlier are gone too? what the hell happen? What is the solution to fix this and get everything back?

Edited by z0ki
Link to comment
27 minutes ago, z0ki said:

Anyone? Its been working fine for years, nothing was changed at all. Why is this happening? 

check cache shares, if they arent set to cache only then its possible files/folders will be moved via the 'mover' to the array.

Link to comment
1 hour ago, binhex said:

check cache shares, if they arent set to cache only then its possible files/folders will be moved via the 'mover' to the array.

 

Not sure I follow? I've had my cache set to be the downloads destination then once complete they get moved to the array? 

 

Not sure why updating to the latest update broke this in deluge? Paths are the same as it was before the latest update on the 4th (if memory serves me correct?) 

 

In preferences even adding the directory clicking apply does nothing. As in once I input a path clicking apply than ok. Then opening preferences again the paths I put are empty. Deluge VPN with the same shares works fine after testing it. I think there is an issue with this specific version? 

 

I'm happy to give you any information needed to try and get this sorted mate :)

 

Only my downloads share is Yes:Cache then when downloads are done it gets moved to DISK 8. 

 

Appdata and system are set to Cache Only

Screenshot_20230506_195058_Edge.jpg

Edited by z0ki
Link to comment
7 hours ago, z0ki said:

Appdata and system are set to Cache Only

this is what i was referring to, ok that sounds fine, next thing to check is that the path set for /config is set to the location of your  config files on the host, perhaps for some reason this got reset, data corruption or pebkac perhaps:-

 

left click icon and select edit, scroll down to show more settings and confirm the host path for /config is set to the location you store your config files in e.g. /mnt/cache/appdata/delugevpn/ if its set wrong then correct and apply.

Link to comment
6 hours ago, binhex said:

this is what i was referring to, ok that sounds fine, next thing to check is that the path set for /config is set to the location of your  config files on the host, perhaps for some reason this got reset, data corruption or pebkac perhaps:-

 

left click icon and select edit, scroll down to show more settings and confirm the host path for /config is set to the location you store your config files in e.g. /mnt/cache/appdata/delugevpn/ if its set wrong then correct and apply.

 

The config is pointing to the right parth - image.thumb.png.2743d3c948831cd8b1b84bafc5f652aa.png

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.