[[Support] binhex - Deluge]

3 minutes ago, martinuv said:

Apologies for dragging this up again, cleanly shutting down deluge seems to have been a problem since it's inception lol. I have managed to 'Quit & Shutdown Daemon' from the windows client as mentioned above (does option not exist in the web client?), which seems to have resolved most of the issues I had previously with stopping the docker container from unraid.

The issue I'm having now is that the daemon restarts itself. So if I need to shutdown the container for whatever reason I have to 'Quit & Shutdown Daemon', wait long enough that it shuts down cleanly, but not too long or it will have started again.

 

I assume there's something in the Binhex container that's recognizing that the process is no longer running and starting it up again? Can I stop this somehow?

My experience is exactly the opposite, I have Deluge running for many weeks before restarting, and have no issues when restarting the container from the dashboard in unraid.

 

I used to do what I had mentioned and use quit and shutdown, and it did not restart itself...I'm not sure what init changes were made that may have changed this behavior, but consider I believe it ran with -d it shouldn't restart the daemon, I had a crash a few days ago during some testing of some stuff, and the daemon didn't relaunch. deluge-web kept running but was not connected to any daemon, the two are not mutually exclusive.

 

Edit: If you want to stop the daemon from the webui, go to connection manager, and select the daemon and hit stop daemon.

[<Support> ambipro - cross-seed]

Hi guys, I'm ambipro (zakkarry @ GitHub) and I'm a developer on cross-seed.

 

We have only had an unofficial Community App thus far, and we decided it was time to get an official one up. It's available now!

 

Please post any issues or questions you may have regarding this container specifically in this thread

(For broader core issues, we may ask you to create an issue on our repository as well for tracking)

 

Repositories

• GitHub: https://github.com/cross-seed/cross-seed
• Official Containers: https://github.com/cross-seed/cross-seed/pkgs/container/cross-seed
• DockerHub Mirror: https://hub.docker.com/r/crossseed/cross-seed/

 

Documention/Support

• unRAID Tutorial: https://www.cross-seed.org/docs/tutorials/unraid
• Getting Started with cross-seed: https://www.cross-seed.org/docs/basics/getting-started

 

If you are not using unRAID you can head over to our Discord. You can find our server on our site (click the Discord Logo in the top right).

https://cross-seed.org

 

Non-unRAID users please do not post in this thread for support.

[[Support] binhex - Deluge]

6 minutes ago, rogales said:

@ambi just sent You a message.

 

Where? I see nothing.

[[Support] binhex - Deluge]

2 hours ago, binhex said:

both are available, use tag name 'libtorrentv1' if you want to use v1

Seems to be working, even did a restart of the container from the dashboard (without quit and shutdown) and no issues.

 

Thanks so much

[[Support] binhex - Deluge]

24 minutes ago, rogales said:

Hello there,

 

I don't want to disturb Your actual problem/testing here, but Id like to ask is there any possibility to start/stop specific number of torrents, at specific hours?
I have cache ssd to hdd type of share configured, and Id want to stop all (earlier moved to HDD) data for a 6 hours, on every night, BUT I would like all torrents that are currently on the cache ssd drive to be active all the time. AND each torrent added (via autobrr, for example) was also downloaded and seeded (because it is on the cache ssd drive)

 

is something like this possible on binhex deluge v2? If so, than how could I manage to do that?

 

thank You

I don't want to hijack this thread....but I've written a script for unRAID, and written the guide for it, to do what I assume your end goal is.

 

https://github.com/zakkarry/deluge-mover

 

https://trash-guides.info/Downloaders/Deluge/Tips/Unraid-Mover/ for the detailed guide. I'm working on updating it to be current with the scripts configuration options I've added just today, but it should be fairly simple for you to set up as it sits.

[[Support] binhex - Deluge]

I assume that this is libtorrent 2.0.9 though?

 

I'd like to stick with 1.2.x (1.2.19 preferrably)

 

Are there plans to offer both with this fix?

[[Support] binhex - Deluge]

No pressure, but I was just curious about when you were going to build and push the dumb-init fix and hopefully update libtorrent (dont forget 1.2.19 in libtorrentv1 branch :D) in the docker images?

 

I assume that the fix worked out how you hoped?

 

Just a curious

[[Support] binhex - Deluge]

07:44:18 [DEBUG   ][deluge.core.daemon            :1622] Remove pid file: /config/deluged.pid
07:44:18 [INFO    ][deluge.core.daemon            :1622] Deluge daemon shutdown successfully
07:44:18 [INFO    ][deluge.core.daemon_entry      :1622] Exiting...

 

deluged exited successfully.

 

07:44:18 [INFO    ][deluge.ui.web.server       :1622] Shutting down webserver
07:44:18 [DEBUG   ][deluge.ui.web.server       :1622] Saving configuration file

 

For thoroughness here is deluge-web.

 

2023-11-13 07:49:28,099 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 22393937543568 for <Subprocess at 22393936472720 with name deluge-script in state RUNNING> (stdout)>
2023-11-13 07:49:28,099 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 22393936863952 for <Subprocess at 22393936472720 with name deluge-script in state RUNNING> (stderr)>
2023-11-13 07:49:28,099 INFO exited: deluge-script (exit status 0; expected)
2023-11-13 07:49:28,100 DEBG received SIGCHLD indicating a child quit
2023-11-13 07:49:46,117 WARN received SIGTERM indicating exit request

 

and Docker logs from when container was stopped

 

Plugins persisted as well.

 

I did go back and test the old image under same conditions (empty config folder). These lines were missing from the logs when the container was stopped, but plugins intermittently did persist regardless. It may not be as consistent as I originally thought to reproduce that way, however it also may have something to do with there being no torrents present and deluged basically being idle throughout the test.

 

Either way, the logs clearly show success in receiving SIGTERM, and waiting for the child processes to return status before container is stopped.

 

I call this a success unless I'm missing something or it reacts differently with torrents loaded (I don't believe it would)

 

 

[[Support] binhex - Deluge]

Alright can test this out right now.

 

Just to reiterate, as I use 1.x libtorrent (which also has 1.2.19, https://pypi.org/project/libtorrent/#history) - and would love to see this and libtorrent updated in both tags when you merge and build the new images.

 

I don't have an issue testing whatever libtorrent version you're using on this branch by the way Just reminding

 

I'll setup a new container with that tag, and test what I've found the most reproducible steps are....just so you can replicate if desired, I'll be doing the following expecting it to work rather than fail.

 

1. New instance of Deluge with empty appdata /config dir

2. Attempt to enable ltConfig plugin (version doesn't seem to matter but we keep an updated version on our forums https://forum.deluge-torrent.org/viewtopic.php?p=236641#p236641) - Default plugins didn't seem to consistently fail to remain loaded for whatever under-the-hood reason.

3. Enable the plug-in in Deluge

4. Restart the container through the unraid UI

 

Plugin should be disabled if the fix hasn't worked....otherwise it should remain (if memory serves).

 

I'll post back when I've done this, if it fails or ungraceful shutdown in logs, will post deluged logs.

 

For clarity, I'm using thin-client to do all of this.

 

 

[[Support] binhex - Deluge]

7 minutes ago, binhex said:

Thanks to you both @mhertz @ambipro -  included the -v flag for info in the image, this will get included in the next image build.

 

In the meantime i shall take a look at dumb-init again and see what is going on, quite disappointed its not working as intended, process management and zombie reaping are a PITA in docker :-(.

You and me both, fortunately there are a few options available if dumb-init can't be worked.

[[Support] binhex - Deluge]

Since I'm the provokation for @mhertz posting this reminder, and as I was going to reach out here myself, I'd like to point out what the request to address this revert/change provides for the user based on my experience using your container and conversations I've had with @mhertz

 

1. A significant portion of the restarting of the container with the ungraceful shutdown can lead to settings being removed, particularly loaded plugins. These will thus not return upon restarting the container.
2. The addition of -v on the info command makes it functional.
3. Graceful shutdown prevents most errors that would otherwise occur with active/seeding torrents, and can also make sure your stats are sent to the tracker before Deluge is exited.
4. Everything else mentioned in his previous posts/code he linked to...

 

The main way to prevent most of these issues currently, that I have found and use, is to simply 'Quit & Shutdown' before restarting or stopping the container. I typically do this and wait about 20 seconds to be safe.

 

This is not ideal, but is workable in most situations.

 

Hoping some form of what has been suggested/mentioned gets added/fixed in both libtorrentv1 and v2 tags.

 

Appreciate your containers and the effort put in, they've otherwise been phenomonal

 

Edit: Also - off topic, but there is a newer version of libtorrent for v1