[bug] (Containerized) Dockchecks self updates currently broken.

@mag37

The current state of Dockchecks self updates when running containerized is not working.
Not the usual script self update.
And not when it finds itself among the containers with new images.

Discussion started in comments (referenced below) and continue in this issue.

Script self update works while its running, but that'll "reset" if it stops+starts (as its not persistent) and will still find docker updates for itself.

Docker self updates crashes the container, it stops it but never starts it properly again.

I'll try to look deeper when I've got time, but either update path is currently not working properly - only a regular docker compose pull && docker compose up -d or similar on the host will work.

Need to think about alternatives.

Originally posted by @mag37 in #261 (comment)

i would keep the update strictly docker image based via docker pull and disable self-updates of the script from inside the container.

@vorezal

@vorezal (and anyone else with input/ideas!) I've looked at a few options to work this out cleanly, just brainstorming here before I push a patch.
When running the docker composed version of Dockcheck we've got the DOCKCHECK_ARGS variable, so my idea has been to use that for now.

First issue: script self update within the container.

Proposed fix is to include checks that DOCKCHECK_ARGS is empty before asking / initiating self update:

-    if [[ "$AutoMode" == false ]]; then
+    if [[ -z ${DOCKCHECK_ARGS:-} ]] && [[ "$AutoMode" == false ]]; then
       read -r -p "Would you like to update? y/[n]: " SelfUpdate
       [[ "$SelfUpdate" =~ [yY] ]] && self_update
-     elif [[ "$AutoMode" == true ]] && [[ "$AutoSelfUpdate" == true ]]; then self_update;
+     elif [[ "$AutoMode" == true ]] && [[ "$AutoSelfUpdate" == true ]] && [[ -z ${DOCKCHECK_ARGS:-} ]]; then self_update;

Second issue: container self update within the container.

Proposed solution is a new bit that always append dockcheck to the new excluded from updates (but still showing) workflow.

if [[ -n "$DOCKCHECK_ARGS" ]]; then
  ExcludeUpdates+=("dockcheck")
fi

Which outputs something like:

Containers with updates available:
01 - apache
** - dockcheck
03 - filebrowser
04 - metube

** = explicitly excluded from being updated

Additionally - if we should use the DOCKCHECK_ARGS way of handling this, maybe we should dedicate a variable within the Dockerfile to work no matter how you run the container?
Like ENV CONTAINERIZED_DC=true or similar. And use that variable for these checks.

(Bonus: The numbered list might be off by one when using the -E option as the count-increment is skipped by mistake, got a fix ready for that. It should be as the example above, not 01,**,02,03, etc)

@jadero

Created a branch for these proposed changes:
https://github.com/mag37/dockcheck/tree/containerized_selfupdate_block

Thank you for your input @jadero btw. I agree it should be image based!
And to clarify, I'll need to investigate if the selfupdate can be solved somehow, but until then we'll block it and people have to resort to doing their manual pull+up.

It seems watchtower has the ability to update itself. Might be worth looking into how they do it.

@yoyoma2

Thanks @yoyoma2 - I've not really had time to dive deeper / move around the logic / see how it behaves.
One line of thought is that if dockcheck is picked for contianer-update, then postpone it and run it as the last thing - though that might still have it crash and leave it hanging.

For now though, I'll push these fixes and look through it properly when back from vacation 😄

I'll take a look in a bit if I can as well, though also when I am back from vacation. Off the top of my head I would like to:

Detect if running in a container and identify the container ID
Skip any self updates (code) if in a container
Push any self updates (container) to the end of the run
Run a single command to pull and update the container. I think certain commands may work for self updates but would need to test.

Everything else is looking pretty good from what I can tell!

I'll push the changes I've made in the branch to main for now and bump a new version, to avoid breakage to peoples workflow.

I just ran a quick and dirty test - I'll write down my steps if anyone else wanna have a go until I'm back home.

Git clone latest release (in a good testing path) and cd into it.
Build image locally and tag (name) it: docker build --load -t mag37/dockcheck:latest .
Copy+Edit the compose (cron + paths), I just set cron to 0 4 * * * and arguments to -n.
Start docker compose up -d
Exec docker exec -it dockcheck /bin/sh

Edit the ./dockcheck.sh (within the container) to add whatever experiment.
I tried a couple of quick things, like adding these lines at the end before the exit 0

docker pull mag37/dockcheck
cd /path/to/my/compose
docker compose recreate 
# or docker compose up -d --force-recreate
# or something else

Save and run ./dockcheck -nx 10 or similar (within the container still).

Then check docker ps -a --filter "name=dockcheck" .
In my case there were 2 containers, one exited (original one) and one created but not started (with a name prefixed by ID like f355b9a06f18_dockcheck) which both disappeared if I

@vorezal

Reopened to continue discussion/work here.

Temporary block/fixes pushed to main, new release v0.8.2 and new image built and published. Added some info to the README and in the release notes.

Grateful for any discussion or testing anyone can contribute with.

And @vorezal your list sounds great, currently I'm relying on the container being named dockcheck to block it from trying to update its own image - which is a bit unreliable but best I could throw together for now.
Using something like docker ps --filter "name=dockcheck" --format '{{.ID}} {{.Names}}' or similar might be a useful source, though risk for multiple matches (like if someone running dockcheck and temporarily a dockcheck_testing).

I think container is misleading direction of bloating and introducing moving parts and complication and attack surface into perfectly functioning script. There is a double edged razor. It just works, nobody needs innovation and cartridge garbage.

@evrial

I think container is misleading direction of bloating and introducing moving parts and complication and attack surface into perfectly functioning script. There is a double edged razor. It just works, nobody needs innovation and cartridge garbage.

I somewhat agree - one core principle have been to try to keep it simple and clean.
Though it have been a wanted feature for quite a while.

That said I think you're right its introducing unwanted complications.

I think we should try to keep it outside the main script. Anything that needs tweaking due to containerization should happen in the image build or external parts and be an afterthought - not set the direction of the main script.

So these changes I've currently made to adhere to the container functionality needs to be moved out and future container features/fixes needs to happen outside of dockcheck.sh.

Does this seem like a reasonable compromise?
I'd love input from anyone involved.
@evrial @yoyoma2 @vorezal and others.

Feature creep can sneak up on you.
I was recently reading a complaint from a linux user that the tar command when using -C required the target directory to already exist and provided no argument to create it if it didn't exist. The answer was that the *nix philosophy has always been to do a small specific task and do it well. Your core principle "keep it simple and clean" is in line with that. 👍

Totally, tar is 47 years old and survived from age of tapes thanks to ignoring the feature creep and pull requests from dumb people. I would strip the half of existing features already.
UPD. looking at 12 months changes, I reverted v0.5.6.0 because nothing of value lost.
UPD2. Made an alternative that meets my expectations https://github.com/evrial/dockcheck

@evrial

I'd love to keep everything compartmentalized as much as possible as well, that way people can choose to use the parts of the script that work for them. Prior to handling self updates at least I would have seen the Docker additions as a completely optional installation method with no impact to the script itself. Users could choose to adopt that method and accept the risk of running it in Docker, which is documented. I'll think on it, but I'm not sure handling self updates can be separated from the main script, at least not entirely. We'll see though.

I don't think I agree with the view that adding example Docker configurations to the project and publishing containers significantly adds moving parts or attack surface to deal with. If both the Bash script itself and the containerized version of the script are the same, Docker just provides users another option to run it. Both have distinct potential attack vectors, but they will only apply to whichever option the users chooses rather than being additive. Both the Bash script and Docker container effectively have root access to the host system. Just my opinion though.

At least speaking for myself, I've proposed and contributed features I've wanted in the hopes they would be useful to others. I'm sure that's true for everyone that has contributed to the project, both before and after v0.5.6.0. Sorry to hear that hasn't met your needs @evrial, but I'm glad you were able to create a solution that does exactly what you want instead.

@mag37

I'm still using dockcheck. I even upgraded to the latest version to help with testing even though I don't need the new features. @mag37 has always done a good job of keeping existing configurations working as dockcheck has moved forward.

Feature creep is subjective. At one point user requests will become about more and more fringe workflows. I saw the dockerization changes and personally wasn't worried about that stuff existing since I don't even use it on my main systems.

@evrial

So first to continue on my keep it simple and clean statement. I understand it doesn't fit with all the features and tweaks implemented, but what I meant was that the core script should be possible to run without any setups, configuration or additions. And while its quite feature rich I've tried to keep the implementations to not interfere or mess with eachother too much. Which is hard when things are continuously bolted on bit by bit.

Totally, tar is 47 years old and survived from age of tapes thanks to ignoring the feature creep and pull requests from dumb people. I would strip the half of existing features already. UPD. looking at 12 months changes, I reverted v0.5.6.0 because nothing of value lost. UPD2. Made an alternative that meets my expectations https://github.com/evrial/dockcheck

@evrial
Thank you for speaking up! I'm sorry you feel its too bloated for your use though good on you to take it into your own hands making your own tool that does just what you need it to do.
Though as it's not forked from dockcheck nor is it mentioned in the description - maybe using the same name could be avoided?

@vorezal
I was looking at the containerization as a complete separate/optional addition too that didn't have to touch the main script and don't see any reason why it'd need to in the future either - except for handling the self updates that is, we'll need to experiment on that one but one thought is that the image build/entrypoint could source some other function or likely if that's needed.

And about the attack surface and risk I agree it has the same level of access and is not additive or lesser/worse in itself while I also understand the feeling of opening "another" vector through the container.
I'm very grateful to you and others who contributed to the project and are happy to try to implement them as best as we can, together.

While I've said no to some feature requests or suggestions I see this as a community project - if there's people that would benefit from a functionality that does not break other things I think it's worth considering!

@yoyoma2
Thank you for your words and considerations. Feature creep is real - but this project hasn't had a single clear scope to start with, it bloomed from just checking for updates without pulling them and then together with the community things slowly added on. Started to grab the updates and actually apply and restart the containers, then notifications etc. And people like you are so valuable - bringing thoughts and discussions, other views and angles.

I don't have the technical details worked out yet, but I took a look at the source code of some other dockerized container update projects for guidance on how to do this properly. While the strategy for handling self-updates is straightforward, it would definitely require the script to know it was itself running within docker and perform have logic specific to that case. I'll try to get to a PR so we can at least evaluate a solution, but the basic idea is to pull an updated image and start another copy of the dockcheck container with the same settings while the original is still running. The old copy would then have to terminate itself, and the new one may need to be responsible for cleanup.

@vorezal

Thank you for continue to look into this @vorezal . And I think it's just fine some bits in the main script still to verify its running in a container or not!
But try to keep it minimal and source modular things from a separate script or modify / add with the container build.

Not clear on how, depends on how large parts have to be modified.

!15221 merge bump-dockcheck-0.8.2 into main

Navigation Menu

Repository navigation

[bug] (Containerized) Dockchecks self updates currently broken. #298

First issue: script self update within the container.

Second issue: container self update within the container.

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

[bug] (Containerized) Dockchecks self updates currently broken. #298

Description

Activity

jadero commented on Jul 25, 2026

mag37 commented on Jul 26, 2026

First issue: script self update within the container.

Second issue: container self update within the container.

mag37 commented on Jul 26, 2026

yoyoma2 commented on Jul 27, 2026

mag37 commented on Jul 27, 2026

vorezal commented on Jul 27, 2026

mag37 commented on Jul 27, 2026

mag37 commented on Jul 27, 2026

evrial commented on Jul 27, 2026

mag37 commented on Jul 28, 2026

yoyoma2 commented on Jul 30, 2026

evrial commented on Jul 30, 2026

vorezal commented on Aug 2, 2026

yoyoma2 commented on Aug 2, 2026

mag37 commented on Aug 3, 2026

vorezal commented on Aug 22, 2026

mag37 commented on Aug 22, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions