GitHub had some issues today (for some users, not me), and are not properly handling raw.github.com whereas it is handling raw.githubusercontent.com  I've updated the URL to reflect this.

All good today. I just installed it!

 

Thanks!

hi guys, i havent used this plugin in a while, and noticed that when i re-enabled it  and selected "no" to "update all docker applications" that its showing all dynamically named containers from waaaay back (no longer exist), so my update screen looks like this (its actually larger than this but you get the idea):-

 

 

any ideas what i can do to reset the list of containers. running version 2019.01.31 of the plugin on unraid stable 6.6.6

 

I have of course tried an uninstall and re-install of the plugin with the same result as above.

Edited February 21, 20197 yr by binhex

You sure you don't have any orphans images?  (Docker - Advanced view)  The plugin doesn't "Remember" anything, but gathers the list of what the docker system says is installed.

Edited February 21, 20197 yr by Squid

You sure you don't have any orphans images?  (Docker - Advanced view)  The plugin doesn't "Remember" anything, but gathers the list of what the docker system says is installed.

100% sure, no unnamed containers or orphaned images, confirmed via cli.

Sent from my EML-L29 using Tapatalk

5 hours ago, binhex said:

100% sure, no unnamed containers or orphaned images, confirmed via cli.

Sent from my EML-L29 using Tapatalk
 

unRaid *thinks* they are there.  I'm grabbing the info from it.   Not quite sure why it thinks that, but a nuke of the image will certainly fix you up.

8 hours ago, Squid said:

unRaid *thinks* they are there.  I'm grabbing the info from it.   Not quite sure why it thinks that, but a nuke of the image will certainly fix you up.

Yeah I realise a nuke of the image would of course get me back to a nice clean state but I thought it may be of interest to you as to why is happening, I'm assuming that the plugin is not issuing a docker ps -a otherwise it wouldn't be happening, so whatever mechanism is used is reporting different results to what the docker engine is reporting.

Sent from my EML-L29 using Tapatalk
 

Edited February 22, 20197 yr by binhex

9 hours ago, binhex said:

so whatever mechanism is used is reporting different results to what the docker engine is reporting.

You would have to post the output of running this script to see what unRaid thinks is happening

#!/usr/bin/php
<?
require_once("/usr/local/emhttp/plugins/dynamix.docker.manager/include/DockerClient.php");

$DockerTemplates = new DockerTemplates();
echo "Docker Templates\n\n";
print_r($DockerTemplates->getAllInfo());

echo "\n\nDockerContainers\n\n";
$DockerClient = new DockerClient();
print_r($DockerClient->getDockerContainers());
?>

 

I am running plugin version 2019.02.22. In both Unraid 6.6.6 and now 6.6.7, I don't have a list of Docker images appearing under the "Docker Auto Update Settings" tab. I can see all settings available (4 rows on the left + the cron settings on the right), followed by the Apply/Done buttons, and that's it. The "Plugin Auto Update Setting" tab on the other hand, is working as intended. 

 

Removing the plugin and re-installing, hasn't helped. Same for upgrading from 6.6.6 to 6.6.7. Any ideas on how I can fix?

 

Thank you!

The list doesn't appear if you have "update all docker apps" set to be yes  (IE: no point in displaying the list if it'll update everything anyways)

Edited March 2, 20197 yr by Squid

On 3/2/2019 at 4:17 PM, Squid said:

The list doesn't appear if you have "update all docker apps" set to be yes  (IE: no point in displaying the list if it'll update everything anyways)

Sorry I didn't clarify: the behavior I described remains the same regardless of what I select for "update all docker apps" and hit apply (see screenshot). The behavior is the same in the latest version of Chrome and Safari. FWIW, I'm running the Unraid UI on port 8008, as I'm running Nginx on port 80.

Edited March 5, 20197 yr by pitsi
Additional details

56 minutes ago, pitsi said:

Sorry I didn't clarify: the behavior I described remains the same regardless of what I select for "update all docker apps" and hit apply (see screenshot). The behavior is the same in the latest version of Chrome and Safari. FWIW, I'm running the Unraid UI on port 8008, as I'm running Nginx on port 80.

What's your docker page look like?

Just wondering if there is an option to run a script every time I am updating specific unraid docker container? 

 

e.g if I update home-assistant docker - run script to install SSHpass, NetCat, etc....

 

I manage to do it manually (even in the HA GUI) but as usual Automatic is the best

 

p.s my script that I am running manually Via VScode/cloud9 container:

https://github.com/VirtualL/HomeAssistant-Config/blob/master/scripts/install_Comp_after_Update.sh

Is there a way to start the updated docker containers after the automatic update, the are stopped after they where updated, on the docker page autostart is on.

Couldn't find a solution.

 

Running Unraid 6.7.0 RC7

(Also searched for the 'Docker autostart' but can't find it or is the plugin deprecated?)

Edited April 15, 20197 yr by ich777

Is there a way to start the updated docker containers after the automatic update, the are stopped after they where updated, on the docker page autostart is on.
Couldn't find a solution.
 
Running Unraid 6.7.0 RC7
(Also searched for the 'Docker autostart' but can't find it or is the plugin deprecated?)

It's supposed to start then back up if they were running.

Sent via telekinesis

@Squid Thank you for the reply!

If they should start after they automatic updated it doesn't work can confirm that for Unraid v6.7.0-rc7 and Unraid v6.6.7 specificly the containers of Linuxserver.io LetsEncrypt and MariaDB, got two servers running and the stay off after the update.

If you need any logs or anything else i can post them.

No it's my fault.  A piece of experimental code I was working on mistakenly wound up in the release version.  Check for updates

On 4/15/2019 at 9:27 PM, Squid said:

No it's my fault.  A piece of experimental code I was working on mistakenly wound up in the release version.  Check for updates

Thanks, mystery solved!

I had the previous version and it wouldn't update. It said: plugin: run failed: /bin/bash retval: 1

 

I decided to remove CA Auto Update and install it again. Now, I can't install it. I am on version 6.6.7

 

Here is the output when trying to install:

 

plugin: installing: https://raw.githubusercontent.com/Squidly271/ca.update.applications/master/plugins/ca.update.applications.plg
plugin: downloading https://raw.githubusercontent.com/Squidly271/ca.update.applications/master/plugins/ca.update.applications.plg
plugin: downloading: https://raw.githubusercontent.com/Squidly271/ca.update.applications/master/plugins/ca.update.applications.plg ... done




plugin: run failed: /bin/bash retval: 1

Updating Support Links

ca.turbo --> https://forums.lime-technology.com/topic/55671-plugin-ca-auto-turbo-write-mode/#comment-544485
ca.update.applications --> http://lime-technology.com/forum/index.php?topic=53693.0
dynamix.cache.dirs --> http://lime-technology.com/forum/index.php?topic=36543.0

I just tried a clean install no problems.   Maybe post the diagnostics

8 hours ago, Squid said:

I just tried a clean install no problems.   Maybe post the diagnostics

I went and got the diagnostics. Figured I'd look - found my USB drive had died. I overlooked the email about a week ago. Anyways, I switched to a new USB drive and it updated fine.

Feature request:

Plugin updates have a canary period, would it be possible to initiate this for docker updates as well?

Just now, wgstarks said:

Feature request:

Plugin updates have a canary period, would it be possible to initiate this for docker updates as well?

Impossible to do.  I *suppose* I could check the date updated that the authors put in for the change logs, but since many / most authors don't do this because of their builds updating themselves every Friday at 23:00 GMT, it's rather pointless

I understand completely. I was just thinking that many Deluge docker users might appreciate the delay. Maybe just setting auto to off is a better policy.

16 hours ago, wgstarks said:

I understand completely. I was just thinking that many Deluge docker users might appreciate the delay. Maybe just setting auto to off is a better policy.

Unattended updates will always have that problem. Delaying the update won't change that.

 

If you don't check the forum for reported issues before updating, that's on the user. Never apply updates without looking at the changes and checking for reported issues. 35+ years in computer experience talking.

 

I always let updates simmer for a few days, if there is an issue, the guinea pigs will always squeal and alert me. I've never been hit with an issue that could have been avoided by updating right away vs. waiting a week. Granted, there are some situations on public facing machines where securing against an imminent threat is required, but I don't run any machines that can't be temporarily firewalled until the situation is more thoroughly investigated.