[BUG] up Incorrectly recreates containers with no changes

[thedanbob]

Description

Since updating to 2.16, docker compose up incorrectly recreates containers when they haven't changed. This only appears to happen for services that are defined in another file and included with extends.

Steps To Reproduce

1. Define a service in a separate YAML file and include the file in docker-compose.yml with extends
2. Run docker compose up -d multiple times
3. Service will recreate+start each time

Compose Version

Docker Compose version 2.16.0

Docker Environment

No response

Anything else?

No response

[tanpro260196]

This happens to me too, without extend, any time a service gets an image update, docker compose up always recreate the container even though it's already running the newest image.

One workaround is to manually docker compose down first then docker compose up again.

[songyantao0617]

An easy way to reproduct this issue

version: '3.8'
services:
  foo:
    environment:
      - name=value
    image: ubuntu
    command: tail -f /dev/null

run docker compose up foo -d over and over again , it is normal as previous version. no recreate happend after it has been already created.
But ! , if any change was made in docker-compose.yml ,such as:

version: '3.8'
services:
  foo:
    environment:
      - name=xxxxxxxxxx
    image: ubuntu
    command: tail -f /dev/null

after then no metter how many times you run docker compose up foo -d , the compose will alway recreate the container!

'2.16.0' has this problem

Hope the core developers could notice this issue.

[KeldorDE]

I can confirm the bug. On multiple systems, the containers are restarted on each docker composer up if a new image update was previously downloaded.

[thedanbob]

This happens to me too, without extend, any time a service gets an image update, docker compose up always recreate the container even though it's already running the newest image.

I can confirm the bug. On multiple systems, the containers are restarted on each docker composer up if a new image update was previously downloaded.

Ah! This must be the real bug then, not extends. I noticed that not every service with extends would get recreated at first, but looking back it was definitely the ones with image updates. However, I did notice that docker compose up -d <service> would recreate the image even with no new image or service file change, so maybe extends factors into that. Or maybe that's a separate bug altogether.

[alfonx]

I can confirm this bug for 2.16, too: "docker compose up -d" recreates all containers always. I do not use extends.
Downgrading to docker-compose-plugin=2.15.1 it works again as expected (only recreates when there is a change)

[milas]

There was a regression in v2.16.0 that's fixed by #10275 which would cause Compose to keep re-creating containers unnecessarily on up after the first time.

This will be fixed in the next Compose release.

[fede843]

thanks!

[AnderssonPeter]

Hi I'm having a similar issue but I'm unsure if the fix will work or not..
Docker version: 23.0.1
Docker compose version: v2.16.0

And docker compose seems to recreate my containers for ever if it detects a change once...

1. Initial start
2. Second start no changes (Works as expected the container is not recreated)
3. Start with changes (Works as expected the container is recreated)
4. Start with no changes (Does not work as expected Recreates it)
   No matter how many times I run docker compose up -d --wait it just keeps recreating them, the only workaround seems to be to run docker compose down every time I make a change then it starts working as expected until the next change is made.

Just a theory is the hash only updated on the initial docker compose start? (where is the hash stored?)

[KeldorDE]

@AnderssonPeter Please retry with docker compose version 2.17.0
The bug was fixed in this version. After you run docker compose up one more time, the containers will be created again, after that the bug should not occur anymore.

[AnderssonPeter]

@KeldorDE sorry for my ignorance but how do I install 2.17.0
running apt update && apt-cache madison docker-compose-plugin only shows 2.16.0. (I'm running debian if that could be the issue)

[KeldorDE]

There is nothing wrong with that, it seems that the new compose version is not yet available in the distribution you are using.

I use the manual installation of docker compose, if you want to use it too, you can find the instructions here https://docs.docker.com/compose/install/linux/#install-the-plugin-manually

[danieletorelli]

@KeldorDE Correct me if I'm wrong, but it seems to me that 2.17.0 has not been released yet. The latest release is 2.16.0, and you can verify it yourself by going to https://github.com/docker/compose/releases/latest

[KeldorDE]

Oh, that was my mistake. You are absolutely right, currently version 2.17.0 is only available as a release candidate.
I loaded the version automatically via script and had not paid attention to the exact git tag. Sorry for the confusion ;)

[stickeraugust]

I can confirm this bug as well! When doing a docker compose down and then up it resolves the issue for a while. But then after a while it starts recreating some containers even when there are no changes.

[LewisSpring]

Looks like 2.17.3 is out now. Still waiting for the repository to be updated. Anybody know how long it takes for it to update?

[AnderssonPeter]

It took for ever for 2.17.2 to be available for installation using apt, but now that it is it solved my issue!
Thanks for the great work!

[Linksku]

I'm still getting this issue on Docker Compose v2.23.3 and Docker v25.0.1. If I last ran docker compose up -d more than ~10min ago, then I run it again, it recreates some random containers and their dependents. I don't think this happened often before, but it has reproed 100% of the time for me in the past few days. It doesn't restart anything if I just ran up less than ~10min ago.

The services being restarted are pretty ordinary, e.g.:

'schema-registry': {
    image: 'confluentinc/cp-schema-registry:7.4.2',
    expose: ['8081'],
    ports: ['127.0.0.1:8081:8081'],
    restart: 'always',
    environment: {
      SCHEMA_REGISTRY_HOST_NAME: 'schema-registry',
      SCHEMA_REGISTRY_KAFKASTORE_BOOTSTRAP_SERVERS: 'broker:29092',
      SCHEMA_REGISTRY_LISTENERS: 'http://0.0.0.0:8081',
      SCHEMA_REGISTRY_LOG4J_ROOT_LOGLEVEL: 'WARN',
      SCHEMA_REGISTRY_TOOLS_LOG4J_LOGLEVEL: 'WARN',
    },
    healthcheck: {
      test: ['CMD-SHELL', 'curl -f http://localhost:8081 || exit 1'],
      interval: '10s',
      timeout: '10s',
      retries: 30,
    },
}

Does Docker Compose recreate containers only when the config file changes? If not, what are some other reasons?

[latchy]

Heya,

So I am also still seeing this issue with Docker Engine v25.0.3 and Docker Compose v2.24.5.
I am using a CRON job on a Raspberry Pi Model 4 (PiOS 64-bit Linux/ARM64) to run this bash script..

#!/bin/bash
docker compose -f /path/to/project/docker-compose.yml pull
docker compose -f /path/to/project/docker-compose.yml up -d

Which uses this docker-compose file..

version: '3'
services:
  image-name:
    container_name: image-name
    image: registry/image-name:latest
    restart: always
    environment:
      - VAR_1=VAL_1
      - VAR_2=VAL_2
      - VAR_3=VAL_3

And whenever the CRON job executes, it correctly pulls any new images, but restarts my container even if the image has not been updated.