allow to restart containers without updating mastercontainer, if a mastercontainer update is available

[logan893]

Steps to reproduce

1. mastercontainer update is available - want to store a backup before proceeding
2. Stop all containers, to perform backup
3. Backup Fails
4. Unable to manually restart containers without updating, only "Update mastercontainer" option available

Expected behavior

Should be possible to restart containers without performing "update mastercontainer", e.g. if backup failed

Actual behavior

Can only proceed with "update mastercontainer", or accept that nextcloud remains down

Other information

Host OS

Ubuntu 22.0.4 LTS

Output of sudo docker info

Client: Docker Engine - Community
Version: 25.0.3
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.12.1
Path: /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.24.5
Path: /usr/libexec/docker/cli-plugins/docker-compose

Server:
Containers: 13
Running: 1
Paused: 0
Stopped: 12
Images: 27
Server Version: 25.0.3
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
Swarm: inactive
Runtimes: runc io.containerd.runc.v2
Default Runtime: runc
Init Binary: docker-init
containerd version: ae07eda36dd25f8a1b98dfbf587313b99c0190bb
runc version: v1.1.12-0-g51d5e94
init version: de40ad0
Security Options:
apparmor
seccomp
Profile: builtin
cgroupns
Kernel Version: 5.15.0-124-generic
Operating System: Ubuntu 22.04.4 LTS
OSType: linux
Architecture: x86_64
CPUs: 3
Total Memory: 5.783GiB
Name: nextcloud44
ID: e188dd7e-dacf-40b6-8ee7-2ee7bb18e9cb
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false

Docker run command or docker-compose file that you used

Other valuable info

[szaimen]

accept that nextcloud remains down

It is possible to start them via CLI:
docker start $(docker ps -a --format {{.Names}} | grep nextcloud-aio | grep -v "borgbackup\|watchtower" )

Afterwards reload the AIO interface and you should see the new state.

[logan893]

accept that nextcloud remains down

It is possible to start them via CLI: docker start $(docker ps -a --format {{.Names}} | grep nextcloud-aio)

Unfortunately this is not a solution. I just tried this, and it was perhaps not the best choice. But, now it's done.

It automatically started the mastercontainer update, at least that is what the AIO web admin UI told me, so that was unavoidable it seems, and the ticket is still valid. Now I am running Nextcloud AIO 9.7.0, before I was able to create a backup as I was intending.

This command also started the backup container, so now that is running while the other containers are starting. I manually stopped the container, since it typically asks you to stop the containers before running a backup.

[szaimen]

It automatically started the mastercontainer update, at least that is what the AIO web admin UI told me, so that was unavoidable it seems

You probably would have needed to reload the aio interface as it is only recreated on reload. So the command should have done its job and afterwards reloading should have shown the new state to you.

[szaimen]

This command also started the backup container, so now that is running while the other containers are starting. I manually stopped the container, since it typically asks you to stop the containers before running a backup.

Right. forgot about the backup container.

[szaimen]

I'll move this to the ideas section as this would be a new feature.

[logan893]

It automatically started the mastercontainer update, at least that is what the AIO web admin UI told me, so that was unavoidable it seems

You probably would have needed to reload the aio interface as it is only recreated on reload. So the command should have done its job and afterwards reloading should have shown the new state to you.

I wanted to avoid any changes before a backup was completed. And backup failed, for reasons (separate discussion ticket).

But, with starting the containers, the mastercontainer update was forced. Is this unavoidable?

[szaimen]

But, with starting the containers, the mastercontainer update was forced. Is this unavoidable?

I think it also started the watchtower container which does the update.

So my fault again. I just updated the instructions.