Enabled services are not detected from docker version 24.0.3

I have two services named docker_service_a and docker_service_b.
docker_service_b depends on docker_service_a as follows:

docker_service_a:
    profiles: [ "noetic" , "noetic_launch", "noetic_auto" ]
    depends_on:
      docker_service_b:
        condition: service_healthy

docker_service_b:
    profiles: [ "noetic" , "noetic_launch" ]
    healthcheck:
      test: . /opt/ros/noetic/setup.sh && rostopic info /certain_rostopic
      interval: 5s
      timeout: 90s
      retries: 3
      start_period: 360s

When I try to docker down only the docker_service_a container, I receive the following error (even though the health status of docker_service_b is healthy)

docker compose --profile=noetic_auto down
service docker_service_b is required by docker_service_a but is disabled. Can be enabled by profiles [noetic noetic_launch]

The above error happens starting from docker version 24.0.3.
I have tried for docker version 24.0.2 and its working fine.

Any help would be highly appreciated!!!

The behvior of Docker Desktop shouldn’t depend on the version of the docker engine. I would bet that you had different compose versions too.

I can also imagine that it was a bugfix, as you want to delete a service which has a dependency, but the dependency is not in the same profile. It would be logical to say we don’t want the compose down command affect services in profiles that was not specified in the compose command.
If you find out what the compose version difference was, you can check the release notes to see if it was a bugfix: Docker Compose release notes | Docker Docs

It seems there’s a compatibility issue with Docker version 24.0.3, leading to errors when bringing down only docker_service_a. Check for updates or bug reports related to this version. Meanwhile, using Docker version 24.0.2 could serve as a temporary workaround until the issue is resolved.

Thank you for your response.
I searched for possible bugs related to the version 24.0.3 and found this.
Could it be related?

@rimelek Yes you were right. The versions of docker compose were also different. I am not able to figure out the exact docker compose version from which the issue occurs yet. The last docker compose version where the error did not occur is Docker Compose version v2.16.0.

No. That is related to live-restore, upgrading Docker and failing to start the docker daemon. The issue is not even similar.

@rimelek Understood.
I found a different post about this issue.
Then I tried restarting the container using docker restart <container_name> instead of docker compose ... restart and it worked.
Is this method ok to use?

@rimelek

No. That is related to live-restore, upgrading Docker and failing to start the docker daemon. The issue is not even similar.

About the above, why I thought it was related:
The file /etc/docker/daemon.json is missing in the systems where enabled services are not being detected.
The file is present in the systems (with docker version 24.0.2 or lower) where the issue doesn’t occurr.

yes

The daemon.json is not created automatically. If it exists on some systems, it means someone or something created it to customize daemon configuration. That is completely normal, but the daemon json is not mentioned in the linked issue either.

1 Like