docker
docker compose up recreates running container that does not have their configs changed in docker-compose.yml
Description
docker compose up stops and recreates running containers that do not have their config changed.
Steps to reproduce the issue:
- Run
docker compose up - Change config for one service in
docker-compose.yml - Run
docker compose upagain
Describe the results you received: A lot of containers that are not related to the service that has its config changed are recreated and restarted.
Describe the results you expected: Only the container of the service that has new config should be recreated and those that depend on it should be restarted.
Additional information you deem important (e.g. issue happens only occasionally): After switching to v2 it happens almost all of the time. Previously on v1 there was no such problem.
Output of docker compose version:
Docker Compose version v2.6.0
Output of docker info:
Client:
Context: default
Debug Mode: false
Plugins:
app: Docker App (Docker Inc., v0.9.1-beta3)
buildx: Docker Buildx (Docker Inc., v0.8.2-docker)
compose: Docker Compose (Docker Inc., v2.6.0)
scan: Docker Scan (Docker Inc., v0.17.0)
Server:
Containers: 45
Running: 39
Paused: 0
Stopped: 6
Images: 36
Server Version: 20.10.17
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
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 logentries splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 10c12954828e7c7c9b6e0ea9b0c02b01407d3ae1
runc version: v1.1.2-0-ga916309
init version: de40ad0
Security Options:
apparmor
seccomp
Profile: default
cgroupns
Kernel Version: 5.15.0-40-generic
Operating System: Ubuntu 22.04 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 11.66GiB
Name: aardvark-vm
ID: CKOC:QAHC:ZJ6M:5INA:JRIE:BFCW:EUIA:OCHV:BRZ2:MF3K:C4PO:EGDQ
Docker Root Dir: /var/lib/docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Additional environment details:
I can't reproduce locally. Can you provide a sample compose file? I tried with this,
version: '3.7'
networks:
none: {}
services:
one:
image: 'ubuntu:focal'
command:
- sleep
- 1d
networks:
- none
two:
image: 'ubuntu:focal'
command:
- sleep
- 1d
Once without network then with for the one service.
@debdutdeb I tried with your compose file, and ran docker compose up -d twice (with around one minute in between) without modifying anything.
The first run, both of the containers came up. This is expected. The second run, both of them are recreated, but I did not modify anything.
Afterwards, I tried it again, it does not happen. Even with modified compose file, it doesn't always occur.
Noticed i was using 2.0.something - old fork of mine. Checking again with 2.6.x.
Yea, it does not always occur, yet I don't see a pattern as to why it occurs when it occurs
I think the mechanism for determining config changes is by hashing the config and storing that hash in the label com.docker.compose.config-hash.
You can check if the label changes between invocations to further verify what's going on.
Different compose executable versions will sometimes produce different hash outputs on the same config file, so make sure tests are done with a consistent binary version.
I'm facing this issue in docker-compose 2.11.2. To reliably reproduce :
Compose file
version: '3.2'
services:
router:
image: httpd:2.4
depends_on:
- one
database:
image: docker.io/centos/postgresql-12-centos7
one:
image: alpine:latest
depends_on:
- database
two:
image: alpine:latest
depends_on:
- router
Pre-condition:
- images in composer file is not available locally (alpine:latest, httpd:2.4, centos/postgresql-12-centos7). If they already exist, remove them.
Step:
docker-compose up -d.sleep 90(optional and doesn't affect the result)docker-compose run --rm two echo 123. All running containers will be recreated at this step
Note
- It occurs if the images are not available locally
- it doesn't occur if the service is started with
--no-depsor service has no linked services
I'm getting the same issue and all images are available locally.
In my case, it's triggered by a docker-compose run, and a linked running container gets recreated even though nothing has changed.
I checked the hash, it does not change across the unexpected recreates.
EDIT: as pointed out in #10068, in my case the result of docker-compose config --hash <service> does not change, but the result of docker inspect <container> -f '{{json .Config.Labels}}' | jq -r '."com.docker.compose.config-hash"' does change
v2.12.0
Seeing this issue on v2.14.0 too - any word on a fix? We have a use cae where we need to gradually add some services to the compose file and start them only after confirming the previous service is happy and healthy.
After I commented on this, I discovered the flag “-- no-recreate” which seems to solve the problem for me. But I don’t understand why this behaviour isn’t the default. Note we just moved from compose 1.x to latest 2.x so still figuring out a few changes.
After I commented on this, I discovered the flag “-- no-recreate” which seems to solve the problem for me. But I don’t understand why this behaviour isn’t the default. Note we just moved from compose 1.x to latest 2.x so still figuring out a few changes.
That flag shouldn't be the default, you're just working around the bug.
Hi guys, this is a pretty bad regression on well established behaviour of docker compose. We will likey need to return to version 1.x until this is addressed - what needs to happen to have the core developers take a serious look at this?
I'm facing this issue in docker-compose 2.11.2. To reliably reproduce :
Compose file
version: '3.2' services: router: image: httpd:2.4 depends_on: - one database: image: docker.io/centos/postgresql-12-centos7 one: image: alpine:latest depends_on: - database two: image: alpine:latest depends_on: - routerPre-condition:
- images in composer file is not available locally (alpine:latest, httpd:2.4, centos/postgresql-12-centos7). If they already exist, remove them.
Step:
docker-compose up -d.sleep 90(optional and doesn't affect the result)docker-compose run --rm two echo 123. All running containers will be recreated at this stepNote
- It occurs if the images are not available locally
- it doesn't occur if the service is started with
--no-depsor service has no linked services
@sillidev does it not make sense to recreate those containers if the one you're running (run means a new container than what up -d created) depends on those directly or indirectly? ~You lost me there. This doesn't seem like a regression.~
rethinking - if run creates a new container to "run" a command, maybe it should run the dependencies individually as well?
@debdutdeb It worked in 2.2.x I believe. This is a regression. It's also nonsense behaviour, there's no way on earth it is desirable.
Here is my example for you. It definely seems to be something that only occurs after an initial docker-compose up when all container images are initially pulled. As an example here is a bringing up our docker compose stack ( i have redacted unimportant details like container names and aws account id):
docker-compose.yml:
services:
image1:
image: "XXX.dkr.ecr.ap-southeast-2.amazonaws.com/image1:3.24-pdns-815"
restart: always
env_file:
- .env_image1
network_mode: host
image2:
image: "XXX.dkr.ecr.ap-southeast-2.amazonaws.com/image2:4.5.10-pdns-817"
restart: always
env_file:
- .env_image2
network_mode: host
depends_on:
- image1
- image4
image3:
image: "XXX.dkr.ecr.ap-southeast-2.amazonaws.com/image3:1.7.0-pdns-818"
restart: always
env_file:
- .env_image3
network_mode: host
depends_on:
- image2
- image4
image4:
image: "XXX.dkr.ecr.ap-southeast-2.amazonaws.com/image4:1.1.0-15-pdns-816"
restart: always
env_file:
- .env_image4
network_mode: host
terminal log:
Docker Compose version v2.14.0
[root@node1 app]# docker-compose up -d
[+] Running 29/29
⠿ image1 Pulled 30.7s
⠿ 6574ba89521b Pull complete 15.1s
⠿ 8902fabd21c4 Pull complete 19.0s
⠿ d67b4bd3dc20 Pull complete 27.2s
⠿ 671b7515a67d Pull complete 30.4s
⠿ image2 Pulled 41.1s
⠿ 0b8f6a5170dd Pull complete 15.6s
⠿ fae6d8344d45 Pull complete 19.0s
⠿ d558aee7005e Pull complete 27.4s
⠿ cb9d85e78c7d Pull complete 30.4s
⠿ 6c725048b9d8 Pull complete 33.5s
⠿ 422273584d09 Pull complete 37.0s
⠿ 0346599eed29 Pull complete 40.7s
⠿ image3 Pulled 33.9s
⠿ 2d473b07cdd5 Pull complete 8.7s
⠿ c76cdcfe63c9 Pull complete 15.9s
⠿ 55aefa35b04b Pull complete 19.3s
⠿ 7f36b87917bc Pull complete 27.6s
⠿ f856414b32cb Pull complete 30.7s
⠿ e393c8fa99fb Pull complete 33.6s
⠿ image4 Pulled 52.4s
⠿ 947f4597baac Pull complete 17.0s
⠿ 49e518ebd03f Pull complete 20.4s
⠿ b0339eef8b27 Pull complete 28.8s
⠿ 035ed68cc5f4 Pull complete 32.5s
⠿ ebf6fe409694 Pull complete 36.5s
⠿ 547b0ba3a806 Pull complete 40.1s
⠿ 355848600dc5 Pull complete 44.5s
⠿ cb87d03f3022 Pull complete 52.1s
[+] Running 4/4
⠿ Container app-image1-1 Started 2.0s
⠿ Container app-image4-1 Started 2.2s
⠿ Container app-image2-1 Started 3.3s
⠿ Container app-image3-1 Started 4.8s
[root@node1 app]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
5b8e278c06c8 XXX.dkr.ecr.ap-southeast-2.amazonaws.com/image3:1.7.0-pdns-818 "/run.sh" 13 seconds ago Up 7 seconds app-image3-1
955a3d575558 XXX.dkr.ecr.ap-southeast-2.amazonaws.com/image2:4.5.10-pdns-817 "/run.sh" 13 seconds ago Up 8 seconds app-image2-1
1b885da37802 XXX.dkr.ecr.ap-southeast-2.amazonaws.com/image4:1.1.0-15-pdns-816 "/run.sh" 13 seconds ago Up 10 seconds app-image4-1
3c75b6d7985e XXX.dkr.ecr.ap-southeast-2.amazonaws.com/image1:3.24-pdns-815 "/run.sh" 13 seconds ago Up 10 seconds app-image1-1
Then down one of the running containers and use docker-compose up -d to bring it back. You will notice that this version recreated ALL the containers where as the docker-compose 1.x only restarts the stopped container:
[+] Running 4/4
⠿ Container app-image1-1 Started 12.9s
⠿ Container app-image4-1 Started 12.9s
⠿ Container app-image2-1 Started 10.9s
⠿ Container app-image3-1 Started 0.7s
[root@node1 app]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
446e24f7223f XXX.dkr.ecr.ap-southeast-2.amazonaws.com/image3:1.7.0-pdns-818 "/run.sh" 18 seconds ago Up 17 seconds app-image3-1
60c6f99f595e XXX.dkr.ecr.ap-southeast-2.amazonaws.com/image2:4.5.10-pdns-817 "/run.sh" 18 seconds ago Up 17 seconds app-image2-1
4e235b8e1d4f XXX.dkr.ecr.ap-southeast-2.amazonaws.com/image4:1.1.0-15-pdns-816 "/run.sh" 29 seconds ago Up 17 seconds app-image4-1
715caa360281 XXX.dkr.ecr.ap-southeast-2.amazonaws.com/image1:3.24-pdns-815 "/run.sh" 31 seconds ago Up 17 seconds app-image1-1
If I then stop one container again, and then use docker-compose up -d to restart it, it now behaves as per ver 1.x and simply restarts the one stopped container:
446e24f7223f
[root@node1 app]# docker-compose up -d
[+] Running 4/4
⠿ Container app-image1-1 Running 0.0s
⠿ Container app-image4-1 Running 0.0s
⠿ Container app-image2-1 Running 0.0s
⠿ Container app-image3-1 Started 0.2s
[root@node1 app]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
446e24f7223f XXX.dkr.ecr.ap-southeast-2.amazonaws.com/image3:1.7.0-pdns-818 "/run.sh" 2 minutes ago Up About a minute app-image3-1
60c6f99f595e XXX.dkr.ecr.ap-southeast-2.amazonaws.com/image2:4.5.10-pdns-817 "/run.sh" 2 minutes ago Up 2 minutes app-image2-1
4e235b8e1d4f XXX.dkr.ecr.ap-southeast-2.amazonaws.com/image4:1.1.0-15-pdns-816 "/run.sh" 2 minutes ago Up 2 minutes app-image4-1
715caa360281 XXX.dkr.ecr.ap-southeast-2.amazonaws.com/image1:3.24-pdns-815 "/run.sh" 2 minutes ago Up 2 minutes app-image1-1
I can consistently reproduce this, their is a clear issue here. Note that this also occurs if after an initial up, where all images are pulled, you then edit the docker-compose file and update the image tag of one of the containers and do a docker-compose up -d it will recreate all containers, howeve if you then try again, it will only recreate the container with the change tag as one would expect. Example of this:
[+] Running 29/29
⠿ image1 Pulled 31.1s
⠿ 6574ba89521b Pull complete 15.0s
⠿ 8902fabd21c4 Pull complete 18.9s
⠿ d67b4bd3dc20 Pull complete 22.0s
⠿ 671b7515a67d Pull complete 30.6s
⠿ image3 Pulled 35.6s
⠿ 2d473b07cdd5 Pull complete 9.1s
⠿ 503ef0ec4674 Pull complete 16.0s
⠿ 54c9d1a0a364 Pull complete 19.3s
⠿ 4feacd948f81 Pull complete 27.3s
⠿ 1a92e2c17952 Pull complete 31.6s
⠿ 6fb7664ee72e Pull complete 35.2s
⠿ image4 Pulled 46.1s
⠿ 947f4597baac Pull complete 17.3s
⠿ 49e518ebd03f Pull complete 20.4s
⠿ b0339eef8b27 Pull complete 28.5s
⠿ 035ed68cc5f4 Pull complete 32.9s
⠿ ebf6fe409694 Pull complete 36.7s
⠿ 547b0ba3a806 Pull complete 39.6s
⠿ 355848600dc5 Pull complete 42.5s
⠿ cb87d03f3022 Pull complete 45.7s
⠿ image2 Pulled 40.9s
⠿ 0b8f6a5170dd Pull complete 16.1s
⠿ fae6d8344d45 Pull complete 19.4s
⠿ d558aee7005e Pull complete 27.4s
⠿ cb9d85e78c7d Pull complete 31.0s
⠿ 6c725048b9d8 Pull complete 34.4s
⠿ 422273584d09 Pull complete 37.7s
⠿ 0346599eed29 Pull complete 40.6s
[+] Running 4/4
⠿ Container app-image4-1 Started 5.7s
⠿ Container app-image1-1 Started 5.7s
⠿ Container app-image2-1 Started 3.1s
⠿ Container app-image3-1 Started 4.4s
[root@node1 app]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ef1b04657e24 XXX.dkr.ecr.ap-southeast-2.amazonaws.com/image3:1.7.0-pdns-606 "/run.sh" 13 seconds ago Up 7 seconds app-image3-1
bb7c0066faac XXX.dkr.ecr.ap-southeast-2.amazonaws.com/image2:4.5.10-pdns-817 "/run.sh" 13 seconds ago Up 9 seconds app-image2-1
0ae1ce6a293f XXX.dkr.ecr.ap-southeast-2.amazonaws.com/image4:1.1.0-15-pdns-816 "/run.sh" 17 seconds ago Up 10 seconds app-image4-1
8441f2fd7272 XXX.dkr.ecr.ap-southeast-2.amazonaws.com/image1:3.24-pdns-815 "/run.sh" 17 seconds ago Up 10 seconds app-image1-1
[root@node1 app]# vim docker-compose.yml
***THE IMAGE TAG WAS CHANGED IN VIM HERE***
[root@node1 app]# docker-compose up -d
[+] Running 7/7
⠿ image3 Pulled 11.7s
⠿ 2d473b07cdd5 Already exists 0.0s
⠿ c76cdcfe63c9 Pull complete 8.2s
⠿ 55aefa35b04b Pull complete 11.1s
⠿ 7f36b87917bc Pull complete 11.3s
⠿ f856414b32cb Pull complete 11.4s
⠿ e393c8fa99fb Pull complete 11.5s
[+] Running 4/4
⠿ Container app-image1-1 Started 23.0s
⠿ Container app-image4-1 Started 23.0s
⠿ Container app-image2-1 Started 21.0s
⠿ Container app-image3-1 Started 10.8s
[root@node1 app]#
There seems to be some bug here somewhere
just tried my local fork, couldn't reproduce with the above steps compose file im using
version: '3.2'
services:
router:
image: httpd:2.4
database:
image: httpd:2.4
one:
image: httpd:2.4
two:
image: httpd:2.4
[N] ⋊> ~/D/R/compose on recreate ⨯ docker rmi httpd:2.4; ./bin/build/docker-compose -f /tmp/compose.yml up -d; ./bin/build/docker-compose -f /tmp/compose.yml stop one; ./bin/build/docker-compose -f /tmp/compose.yml up -d
Untagged: httpd:2.4
Untagged: httpd@sha256:87a012bf99bf5e3e0f628ac1f69abbeab534282857fba3a359ca3a3f4a02429a
Deleted: sha256:dc0ffcb6f5c2ffbf82b074a8a875fb771f92cbff7a4f765a8e909544b34e88f5
Deleted: sha256:a46de20bb0879acebd7d4019b20949372e983c9b2734287b5f645d9f4c295473
Deleted: sha256:d8ebf31c170c9c8880f78f88d8c17590764dabc8e7f581fe43f3c9cc991ab810
Deleted: sha256:422dbb594c3ecc7e51ad4f9d53db0b2db7f0bfb9e834750d74c96b3e5742b467
Deleted: sha256:4308bb6033634dee7bac4308a5f7f9548f1ddff2e61e3e5d0d1a94ae24913681
Deleted: sha256:afd7e44a4e086678d666c3721e0e45dc85045db6952832135ea2d32e1a4db966
[+] Running 9/9
⠿ database Pulled 8.2s
⠿ one Pulled 8.2s
⠿ router Pulled 8.2s
⠿ 934ce60d1040 Pull complete 4.0s
⠿ e0c9391b348d Pull complete 4.0s
⠿ e106b5ae0073 Pull complete 4.1s
⠿ 339abac02bc5 Pull complete 5.4s
⠿ 9e37b0a5502a Pull complete 5.4s
⠿ two Pulled 8.2s
[+] Running 5/5
⠿ Network tmp_default Created 0.0s
⠿ Container tmp-database-1 Started 0.6s
⠿ Container tmp-one-1 Started 0.7s
⠿ Container tmp-router-1 Started 0.5s
⠿ Container tmp-two-1 Started 0.6s
[+] Running 1/1
⠿ Container tmp-one-1 Stopped 1.1s
[+] Running 4/4
⠿ Container tmp-one-1 Started 0.2s
⠿ Container tmp-router-1 Running 0.0s
⠿ Container tmp-two-1 Running 0.0s
⠿ Container tmp-database-1 Running
Can't reproduce the tag change either; compose file
services:
one:
image: httpd:2.4
two:
image: httpd:2.4
three:
image: httpd:2.4
four:
image: httpd:2.4
out -
[I] ⋊> ~/D/R/compose on recreate docker rmi httpd:2.4 httpd:2 13:54:04
Untagged: httpd:2
Untagged: httpd@sha256:87a012bf99bf5e3e0f628ac1f69abbeab534282857fba3a359ca3a3f4a02429a
Deleted: sha256:dc0ffcb6f5c2ffbf82b074a8a875fb771f92cbff7a4f765a8e909544b34e88f5
Deleted: sha256:a46de20bb0879acebd7d4019b20949372e983c9b2734287b5f645d9f4c295473
Deleted: sha256:d8ebf31c170c9c8880f78f88d8c17590764dabc8e7f581fe43f3c9cc991ab810
Deleted: sha256:422dbb594c3ecc7e51ad4f9d53db0b2db7f0bfb9e834750d74c96b3e5742b467
Deleted: sha256:4308bb6033634dee7bac4308a5f7f9548f1ddff2e61e3e5d0d1a94ae24913681
Deleted: sha256:afd7e44a4e086678d666c3721e0e45dc85045db6952832135ea2d32e1a4db966
Error: No such image: httpd:2.4
[I] ⋊> ~/D/R/compose on recreate ./bin/build/docker-compose -f /tmp/compose.yml up -d --remove-orphans 13:54:05
[+] Running 9/9
⠿ one Pulled 8.0s
⠿ three Pulled 8.0s
⠿ two Pulled 8.0s
⠿ 934ce60d1040 Pull complete 4.5s
⠿ e0c9391b348d Pull complete 4.6s
⠿ e106b5ae0073 Pull complete 4.7s
⠿ 339abac02bc5 Pull complete 5.2s
⠿ 9e37b0a5502a Pull complete 5.2s
⠿ four Pulled 8.0s
[+] Running 5/5
⠿ Network tmp_default Created 0.0s
⠿ Container tmp-two-1 Started 0.8s
⠿ Container tmp-three-1 Started 0.5s
⠿ Container tmp-one-1 Started 0.7s
⠿ Container tmp-four-1 Started 0.6s
[I] ⋊> ~/D/R/compose on recreate gsed '0,/2.4/ s/2.4/2/1' /tmp/compose.yml -i 13:54:17
[I] ⋊> ~/D/R/compose on recreate ./bin/build/docker-compose -f /tmp/compose.yml up -d --remove-orphans 13:54:30
[+] Running 1/1
⠿ one Pulled 3.0s
[+] Running 4/4
⠿ Container tmp-two-1 Running 0.0s
⠿ Container tmp-three-1 Running 0.0s
⠿ Container tmp-one-1 Started 1.3s
⠿ Container tmp-four-1 Running 0.0s
if I introduce a dependency array -
services:
one:
image: httpd:2.4
depends_on:
- two
two:
image: httpd:2.4
three:
image: httpd:2.4
depends_on:
- one
four:
image: httpd:2.4
out -
[I] ⋊> ~/D/R/compose on recreate ./bin/build/docker-compose -f /tmp/compose.yml up -d --remove-orphans 13:56:19
[+] Running 5/5
⠿ Network tmp_default Created 0.0s
⠿ Container tmp-four-1 Started 0.4s
⠿ Container tmp-two-1 Started 0.4s
⠿ Container tmp-one-1 Started 0.5s
⠿ Container tmp-three-1 Started 0.7s
[I] ⋊> ~/D/R/compose on recreate gsed '0,/2.4/ s/2.4/2/1' /tmp/compose.yml -i 13:56:21
[I] ⋊> ~/D/R/compose on recreate ./bin/build/docker-compose -f /tmp/compose.yml up -d --remove-orphans 13:56:34
[+] Running 4/4
⠿ Container tmp-four-1 Running 0.0s
⠿ Container tmp-two-1 Running 0.0s
⠿ Container tmp-one-1 Started 2.5s
⠿ Container tmp-three-1 Started 1.5s
You'll see it now recreates one and three - which makes sense since I updated one and three depends on one.
I can reproduce on the compose shipped with docker desktop though; 2.6.1 edit:i need to update edir2: wow still on 2.6.1 compose .. urgh
@debdutdeb So we are on:
# docker-compose version
Docker Compose version v2.14.0
and can reproduce it pretty consistently. We are running on centos7 (its a packer built AMI), with docker installed as follows:
# yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
# sudo yum install -y docker-ce
and compose installed as follows:
# export DOCKER_COMPOSE_VER="2.14.0"
# mkdir -p /usr/local/lib/docker/cli-plugins/
# curl -L https://github.com/docker/compose/releases/download/v${DOCKER_COMPOSE_VER}/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/lib/docker/cli-plugins/docker-compose
# chmod +x /usr/local/lib/docker/cli-plugins/docker-compose
# ln -s /usr/local/lib/docker/cli-plugins/docker-compose /usr/bin/docker-compose
what version is your local fork based on and we can install that version and try. We can consistently reproduce this so let me know if other logs or something would also help.
It did happen to me with newer docker-compose binaries. The interesting thing is that some (semi-random) containers got restarted even when working correctly. I've used a very simple script to check if there are new images, and if so - to restart the containers. However, some of the containers got restarted even while working. It seems that if the original cration of these containers (docker-compose up -d) was done using older docker-compose binary (pre v2), the current version would sometimes decide that this container needs restart. I've had to take down all my containers and then start them up using the more modern v2.16 docker-compose binary. FYI.
@debdutdeb I don't see anything in the 2.15.0 changelog which hints that this issue was fixed. What makes you suggest that?
@benlangfeld I tested against the latest tag. Couldn't reproduce the issue with the steps provided, if you look further up the thread, I shared my observations a while ago.
I don't remember exactly but I did track down a specific function call path (mustRecreate?) that i noticed got updated - which made me think the issue probably was fixed already. Will try to retrace when I'm at my desk again.
@debdutdeb We are still working through updating our test environment with the latest version to confirm if we are still seeing the issue or not, we will update here once we know the result either way
I'm seeing this behaviour on 2.16.0. Will try to find a minimal example tomorrow.
