25 minutes ago, alturismo said:

and you also delete image when clicking remove ?

 

may open your docker tab, upper right advanced view, scroll down to the buttom if there are unused images ... (orphan)

Yes, I also deleted any orphan images.

Is Time to wait for graceful stop before killing to wait before killing in seconds?

Good morning,
Is it possible to be notified via Gotify when updates have been performed?

Hello, 

the plugin is fetching somehow an unknowen docker container, any idea where to look for this? Is there a way to find this unknowen image/container?

 

thank you

so I like my settings I have setup for this plugin.

 

I'm curious if there is a way to add a change of update frequency to only 1 docker the rest are fine being weekly but one I have for testing and dev gets updated daily it seems...

 

or is this better done at the userscript level to docker stop pull start?

example:
 

#!/bin/bash

# Define the container name and repository here
CONTAINER_NAME="immich"          # Container name
REPOSITORY="ghcr.io/imagegenius/immich"  # Docker repository

# Stop the container
docker stop $CONTAINER_NAME

# Pull the latest image from the specified repository
docker pull $REPOSITORY

# Start the container again
docker start $CONTAINER_NAME

or clean up as welll:
 

#!/bin/bash

# Define the container name and repository here
CONTAINER_NAME="immich"          # Container name
REPOSITORY="ghcr.io/imagegenius/immich"  # Docker repository

# Stop the container
docker stop $CONTAINER_NAME

# Pull the latest image from the specified repository
docker pull $REPOSITORY

# Remove dangling images (optional: use -a for more aggressive cleanup)
docker image prune -f

# Alternatively, remove all unused images:
# docker image prune -a -f

# Start the container again
docker start $CONTAINER_NAME

? not sure if this plugin will see a update to set a monthly daily weekly per item of a docker container / plugin...

For multiple schedules, you'd have to do it via user scripts

Like the plugin and it works fine. Just a small note:

 

Could you offer the 24hour format for hour like the settings in the Scheduler section?

Hi Squid, quick suggestion as we're seeing more and more use of docker-compose containers (especially w/ SpaceInvaderOne's Nextcloud-AIO video) and seeing the constant notifications of those containers auto-updating on a daily basis, perhaps we could get a setting to auto update all EXCEPT containers we exclude?

 

Right now we can turn off auto updates but only include specific containers (but then any newly added containers don't get auto updated by default) 

 

A setting to auto update all but exclude specific containers would be great and could solve these problems 

 

I've searched around and can't find an answer.  The plugin is trying to delete:

 

kasm: /mnt/user/appdata/

 

I don't have a container named kasm and none shows in docker/advanced either.  Obviously I can't delete /mnt/user/appdata, but would like to keep using this plugin and not worry about missing this.  It's been working great up until this curious deletion target. Thanks!

 

versions: Unraid 7.0.0, CA Cleanup Appdata 2024.03.17

 

3 hours ago, Stephen W said:

I've searched around and can't find an answer.  The plugin is trying to delete:

 

kasm: /mnt/user/appdata/

 

I don't have a container named kasm and none shows in docker/advanced either.  Obviously I can't delete /mnt/user/appdata, but would like to keep using this plugin and not worry about missing this.  It's been working great up until this curious deletion target. Thanks!

 

versions: Unraid 7.0.0, CA Cleanup Appdata 2024.03.17

 

did you check the folder and hit delete selected?

Because its is set to /mnt/user

double-check the share for appdata. App data should only have a primary drive set and not use a secondary...

Mover may be moving files from secondary/primary if you told it too.

make sure its not a path added by another docker.

On 2/3/2025 at 10:03 AM, Stephen W said:

I've searched around and can't find an answer. 

Probably because you didn't find the correct thread.

Read through the support thread, your issue is covered there.

DON'T DELETE /mnt/user/appdata

On 8/27/2021 at 5:04 PM, jimmy898 said:

 

Thanks for the hint!

 

Just to be sure: the script should have the very same name of the container right? So if my container name is 

"zabbix-agent2", the starting script should be "/boot/config/plugins/ca.update.applications/scripts/starting/zabbix-agent2.sh". Right?

I cannot get this working for the life of me. I have added a script as described, but any time I update the container the script does not apply the commands. I don't see anything in the logs on Unraid or the container itself. Not sure what I am doing wrong.

This was asked in 2019, but I didn't see a response. Can anyone answer these questions? They do seem quite important in regards to behavior. 

 

"I have a question about a setting:

 

In the "Docker Auto Update Settings" settings tab, there is the setting "Time to wait for docker graceful stop before killing".  What unit of time does this use?  Seconds or minutes?  What command is used for a graceful stop versus killing?  Does it kill docker or only containers currently running?

 

Thank you!"

21 minutes ago, live4soccer7 said:

This was asked in 2019, but I didn't see a response. Can anyone answer these questions? They do seem quite important in regards to behavior. 

 

"I have a question about a setting:

 

In the "Docker Auto Update Settings" settings tab, there is the setting "Time to wait for docker graceful stop before killing".  What unit of time does this use?  Seconds or minutes?  What command is used for a graceful stop versus killing?  Does it kill docker or only containers currently running?

 

Thank you!"

seconds
a container is usually stopped by sending sigterm, if it doesnt shutdown, its getting a sigkill.
You dont need to kill non-running containers, as theyre not running.

Edit: Apparently i added a word while reading which wasnt there, ups.

No it doesnt kill docker, its using docker to kill the containers. 

Edited March 7, 20251 yr by Mainfrezzer

17 minutes ago, Mainfrezzer said:

seconds
a container is usually stopped by sending sigterm, if it doesnt shutdown, its getting a sigkill.
You dont need to kill non-running containers, as theyre not running.

Edit: Apparently i added a word while reading which wasnt there, ups.

No it doesnt kill docker, its using docker to kill the containers. 

Thank you very much.

2 hours ago, live4soccer7 said:

This was asked in 2019, but I didn't see a response. Can anyone answer these questions? They do seem quite important in regards to behavior. 

 

"I have a question about a setting:

 

In the "Docker Auto Update Settings" settings tab, there is the setting "Time to wait for docker graceful stop before killing".  What unit of time does this use?  Seconds or minutes?  What command is used for a graceful stop versus killing?  Does it kill docker or only containers currently running?

 

Thank you!"

Its in seconds, and effectively issues a docker stop command with an additional parameter for docker itself to kill the container if it hasn't stopped within the period you specified.   This setting predates when the OS added support to change the docker stop timeout in Settings - Docker instead of always using the default 10 seconds from docker itself.

 

IIRC, if you don't set anything then the plugin will use whatever you've set in settings - docker

It would be nice with a notification system to this, like discord webhook

12 minutes ago, Berduf said:

It would be nice with a notification system to this, like discord webhook

If you enable notifications within the plugin, then it sends out notifications (Notices) according to how you've specified them in Settings, Notification Settings.  IE: Any agent you want.

Is it possible for the docker containers to be restarted in the same order they have in the docker tab, instead of alphabetically? I ran into an issue today where redis and authelia were updated at the same time, but authelia failed to start because redis wasn't running first.

 

Also, in searching the thread I've seen reference to a CA manual way back in 2017 (see below). I suppose I could utilize this to work around my specific issue but perhaps restarting in the user defined order on the docker tab would be better...

 

Is there a place where the rest of this CA Manual exists? I can't seem to find it...

 

On 3/18/2017 at 10:41 AM, Squid said:

Added.  Details in the CA manual (Auto Update Applications / Docker Advanced Control)

Advanced Docker Control
Optionally, CA Auto Update supports running custom stop and start scripts for docker applications. These scripts will be executed prior to stopping an application and after starting an application.

To use this feature, create the following file(s) on your flash drive: (They are executed in order if they exist)


/boot/config/plugins/ca.update.applications/scripts/stopping/stop_all	This script will be executed whenever any docker application is being updated (prior to updating)
/boot/config/plugins/ca.update.applications/scripts/stopping/{nameOfContainer}	This script will be executed whenever {nameOfContainer} is being updated (prior to updating)
/boot/config/plugins/ca.update.applications/scripts/starting/{nameOfContainer}	This script will be executed whenever {nameOfContainer} has been updated
/boot/config/plugins/ca.update.applications/scripts/starting/start_all	This script will be executed whenever any container has been updated

Oops: Don't use spaces in container names - (Since I've wound up updating all my containers, I can't fix this until next Friday  )

 

 

I added a stack with 2 Docker containers via Compose Manager. After deleting the stack, Auto Update still detects these containers/images and updates them.

I don't know if this is a problem with Compose Manager or Auto Update (storing unavailable images and updating them).

I checked if '/boot/config/plugins/compose.manager' contains any remnants of the stack, but it does not.

Does Auto Update store a list of containers/images that should be updated?
If yes, what is the location?

See also this question:

 

Edited March 26, 20251 yr by alt13

4 hours ago, alt13 said:

I don't know if this is a problem with Compose Manager

When you do a "Compose down" in Compose manager it removes the containers but not the images, you have to delete them yourself (docker page in advanced mode will show them, or you can use e.g. "docker image prune -a" to remove all unused images)

Edited March 26, 20251 yr by Kilrah

I appreciate your help.
I deleted them. I also ran the command "docker image prune -a" which resulted in 0B because no image was found.
When setting the "Update All Docker Applications" to No, I see the two remnant entries that have no container and no image but still exist in Auto Updater.

 

Edit (Solution): After a reboot, the entries where gone. Sorry that I did not try that earlier and had to bother you.

Edited March 27, 20251 yr by alt13
Found Solution

Does the auto-update on certain dockers work for anyone else? I want to auto-update all my containers other than gluetonvpn, but it seems to ignore and update it anyway.

 

 

 

If you run the appdata backup plugin make sure you didn't enable autoupdate in that. 

Trying to get a script to fire every time I update a container, but it is not working. Any ideas?

• I have created a file under "/boot/config/plugins/ca.update.applications/scripts/starting/".
• I used the exact name of the container "zabbix-agent2" (no .sh). 
• I think it is a valid bash script (see script contents below).
  • I have tried with and without "#!/bin/bash" at the start of the script (no difference).

When I "apply update" manually from the "Docker" tab, the script does not fire (confirmed as the zabbix agent loses Docker data until I manually run the commands that are contained in the script).

 

docker exec --user root zabbix-agent2 sh -c "addgroup -g 281 docker"
docker exec --user root zabbix-agent2 sh -c 'sed -i "s/docker:x:281:/docker:x:281:zabbix/g" /etc/group'