binhex / arch-delugevpn

Docker build script for Arch Linux base with Deluge, Privoxy and OpenVPN
GNU General Public License v3.0
696 stars 112 forks source link

Plugins not enabled on reboot #66

Closed Dulanic closed 5 years ago

Dulanic commented 6 years ago

So I know this has been mentioned before, but I'd like to make an ticket to track research. I am going to dig in a bit more as I have time also to see if I can figure anything out also.

Issue: Plugins lose settings upon container resets.

Dulanic commented 6 years ago

As a follow up, is there a easy way for me to edit the plugin settings upon container start? I wasnt sure what runs on startup. Ill dig in, but if you can specify off hand, might help.

johanndt commented 6 years ago

I don't think it's saving properly. I just tried to turn on the label plugin and while it seems to turn on in the client, I see the following in the logs:

[INFO    ] 20:14:30 core:97 *** Start Label plugin ***
[WARNING ] 20:14:30 config:369 Unable to open config file /config/label.conf: [Errno 2] No such file or directory: '/config/label.conf'
[INFO    ] 20:14:30 pluginmanagerbase:158 Plugin Label enabled..

Looking in /config/core.conf I can see there's a item for "enabled_plugins": [],, and also "plugins_location": "/config/plugins",. But these don't appear to get updated when enabling a plugin.

I guess if we fix this, then it should start working.

I found this thread: https://forum.deluge-torrent.org/viewtopic.php?t=45287

Reading the last message, I tried the same. In the web GUI go to connection manager, stop the daemon. Then restart it. Checking core.conf now shows the Label plugin listed in enabled_plugins.

Dulanic commented 6 years ago

So the enabled plugins seem to work, but sometimes seem to add every time, see https://github.com/binhex/arch-delugevpn/issues/61 . However, the plugin settings are not working. Enabled plugins stays persistent between resets it seems. However, the .conf files for the plugins revert to their default each restart. Label seems to be an exception, so I don't know the cause.

Extractor.conf before restart:

{
  "file": 1, 
  "format": 1
}{
  "use_name_folder": true, 
  "extract_path": "/downloads/extracted"
}

After restart:

{
  "file": 1, 
  "format": 1
}{
  "use_name_folder": false, 
  "extract_path": ""
}

I have validated this works fine outside of docker and manually installed.

johanndt commented 6 years ago

So I had some time to try this again and I enabled the Execute plugin. Then I added 1 command to it's config, and restarted the container with docker restart delugevpn. When I could log in again the config still had the same command I had set in there before:

[root@182bf65f156d config]# cat execute.conf
{
  "file": 1, 
  "format": 1
}{
  "commands": [
    [
      "ab954f596335631ee333d0629c5233c55b245538", 
      "complete", 
      "/bin/true"
    ]
  ]
}

So at least it seems like it's not all plugins forgetting their settings. I'll test the Label plugin next like you did.

ZataH commented 5 years ago

I have the same issue. My SimpleExtract plugin keep resetting it self, and password for deluge does not keep saved.

adampetrovic commented 5 years ago

+1 SimpleExtract is resetting itself between restarts.

sundarnet commented 5 years ago

+1 for labels plugin not remembering its been enabled

binhex commented 5 years ago

from the poking about ive done over time this looks to be a deluge bug, permissions are set correctly, you can add plugins in but some do not 'stick' and others you end up with duplicate entries showing, dunno why, but i got my fingers crossed that this is all fixed in the new shiny deluge 2.x which should be out soon(ish).

Petahh commented 5 years ago

I had similar problem as you guys, bit of manual actions resolved it however. I will sum it up for anyone who is looking for quick solution to this.

  1. Make sure that your plugin conf files are present and accessible. example: config/label.conf
  2. Edit config/core.conf and add below lines to enable plugins, example:
    "enabled_plugins": [
    "Label",
    "Scheduler",
    "Notifications"
    ],
binhex commented 5 years ago

ugghh! sadly this is STILL not fixed in deluge 2.0.3, so looks like its still a manual hack to get plugins to stay enabled, not good :-(

binhex commented 5 years ago

A bit more investigation on this, so it looks like deluge weirdly only saves settings made to plugins section (maybe other settings to?) on shutdown!, problem is of course that because deluge is running in a container, when deluge shuts down so does the entire os (container) and thus there is no chance to write the settings out, resulting in things like enablement of plugins not 'sticking'. in my mind this is a deluge bug.

binhex commented 5 years ago

closing the issue off but leaving pinned, also of note i have now created a FAQ for this issue, see here Q4.:- https://github.com/binhex/documentation/blob/master/docker/faq/delugevpn.md

mattman86 commented 5 years ago

I've enabled the plugins the manual way but I'm still not able to configure them. They aren't showing in the menu in the preferences menu.

MrScottah commented 4 years ago

Still having this issue.

marc0janssen commented 4 years ago

I'm having this issues too

binhex commented 4 years ago

if the plugin is not made for deluge v2 then you will be out of luck until the plugin developer updates the plugin to work with python 3.x

marc0janssen commented 4 years ago

Hi @binhex , Thanks for replying.. but I fixed it with the hint from @Petahh

itsananderson commented 3 years ago

I know this is a very old (and closed) ticket, but I was curious about the root cause of this issue, so I did some digging this evening.

Theoretically Deluge should write its config when it receives a shutdown signal (SIGTERM). In fact, I tested this behavior by running pgrep deluged | xargs kill -TERM on the docker machine. When I did that, the Deluge daemon was shut down, but before it did, it wrote out its config. Eventually watchdog.sh detects that the Deluge daemon isn't running and restarts it.

Normally when a Docker container shuts down, the entrypoint should receive a SIGTERM. However, since Deluge daemon is started as a background process it doesn't automatically receive this SIGTERM signal. It looks like the Docker image is supposed to kill the deluged and deluge-web processes at shutdown but shutdown.sh doesn't actually seem to exist on the latest image. Looking at the Git history of https://github.com/binhex/scripts, I think the issue is that shutdown.sh was only added on December 27th but the latest release of arch-delugevpn was on December 1st, so it's missing the shutdown.sh script. I think that means simply publishing a new version of this Docker image (and thus pulling in the latest binhex/scripts) would be enough to actually fix this bug.

binhex commented 3 years ago

I think the issue is that shutdown.sh was only added on December 27th but the latest release of arch-delugevpn was on December 1st, so it's missing the shutdown.sh script. I think that means simply publishing a new version of this Docker image (and thus pulling in the latest binhex/scripts) would be enough to actually fix this bug.

correct!, shutdown.sh is a relatively new introduction to all of my images, but i have been hesitant about pressing the button at the moment, especially as the issue is reasonably minor for deluge. i will be rebuilding the image at some point im sure, and at that point shutdown.sh wil be included and should finally fix this issue.

itsananderson commented 3 years ago

👍 No need to rush out a new release just for this. I mostly commented for awareness, since it might not have been obvious that the issue will be resolved with the next image update. Plus I spent a couple hours poking at the container to figure out what was going on, so I felt like I should record my findings 😂