Docker compose: automatically attaching to running containers from different docker-compose.yml files

[bynov]

Description
I'm using two different yml files to run different set of services.
Before the last update I did several days ago, I run docker compose -f first.yml and docker compose -f second.yml in different console tabs and all worked fine.

After last update when I'm trying to run second.yml right after first.yml I see that it automatically attaches to services from first.yml. And because of that I can't stop them separately and I see huge log from both services in all my tabs.
I don't see the way how to prevent it and I assume something was changed after last update I did.

Steps to reproduce the issue:

1. Create two separate docker-compose.yml with service name service-1 in first file and service-2 in second.
2. Run first docker-compose file docker compose -f first.yml up and second one in separate tab or console docker compose -f second.yml up

Describe the results you received:
I see that second command automatically attaches to services from first.yml and shows logs from it. Also if I press Ctrl+C in first or second consoe, it will stop service-1 and service-2,

Describe the results you expected:
It should work as previous: logs in different consoles should be separated and if I will press Ctrl+C in first or second console, it should stop only services within manifest file, not all.

Additional information you deem important (e.g. issue happens only occasionally):
Started after last update several days ago.

Output of docker compose version:

Docker Compose version v2.4.1

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc., v0.8.2)
  compose: Docker Compose (Docker Inc., v2.4.1)
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc., 0.6.0)
  scan: Docker Scan (Docker Inc., v0.17.0)

Server:
 Containers: 11
  Running: 0
  Paused: 0
  Stopped: 11
 Images: 228
 Server Version: 20.10.14
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 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: 3df54a852345ae127d1fa3092b95168e4a88e2f8
 runc version: v1.0.3-0-gf46b6ba
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.10.104-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 7.774GiB
 Name: docker-desktop
 ID: PYWY:4MGO:DKO3:DLAS:47WG:5RVQ:MZQ2:5FN2:5WGG:GORD:4RL7:BP6E
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5000
  127.0.0.0/8
 Live Restore Enabled: false

Additional environment details:
It works as I expect at docker desktop 4.5.0. I tried to use 4.6.1 - same invalid behavior.

[henriqueholtz]

@bynov Really. It's seems a bug!

I got some evidents:

My previous version (1.29.2):

After updated to 2.4.1 version:

[diegoquiroz]

Hey, I had this problem myself.
The solution was to delete the network I was using (docker network rm [network-name]) and run the compose up again to re create it.
You're not using an specific network so probably the name of your network is the default one.

[michaeldiscala]

I just saw this after filing yesterday, but I think this may be a manifestation of the same bug that I reported in #9459

When I try out the reproduction steps listed in the ticket before 9d73cc8 is applied, I am not able to reproduce the bug that @bynov describes. When I checkout 9d73cc8 I am able to reproduce this bug.

Should I close my ticket and merge into this one?

[woolfi182]

The same bug for me docker-compose v2.5.1!
I generate some files for running and some are static, so services should be divided.

[changleilei]

Docker Compose version v2.5.0 have same problem.

[glours]

I can't reproduce with the v2.6.1.
Because there isn't a arm64 version of the sonarqube image, I used a little bit more complex sample based on the bitnami/sonarqube image :

services:
  sonarqube:
    image: bitnami/sonarqube
    container_name: sonarqube
    ports:
     - 9000:9000
    environment:
      # ALLOW_EMPTY_PASSWORD is recommended only for development.
      - ALLOW_EMPTY_PASSWORD=yes
      - SONARQUBE_DATABASE_HOST=postgresql
      - SONARQUBE_DATABASE_PORT_NUMBER=5432
      - SONARQUBE_DATABASE_USER=bn_sonarqube
      - SONARQUBE_DATABASE_NAME=bitnami_sonarqube
  postgresql:
    image: docker.io/bitnami/postgresql:13
    volumes:
      - 'postgresql_data:/bitnami/postgresql'
    environment:
      # ALLOW_EMPTY_PASSWORD is recommended only for development.
      - ALLOW_EMPTY_PASSWORD=yes
      - POSTGRESQL_USERNAME=bn_sonarqube
      - POSTGRESQL_DATABASE=bitnami_sonarqube
volumes:
  postgresql_data:
  sonarqube_data:

Can you give more details, are the compose files in the same directory? Are you the compose files in your screenshots complete (no other extra services with maybe links or dependencies with other services)?

Can you also try to a name to your compose file to be sure that compose with manage the both stack with a dedicated namespace? Like that :

name: sonarqube1
services:
  sonarqube:
  ...

[glours]

@bynov @henriqueholtz @diegoquiroz @michaeldiscala @woolfi182 @changleilei can you confirm that you still have the issue with the v2.6.1 or v2.7.0? Otherwise I'll close the issue

[woolfi182]

I checked with different configs and it works well for me. I don't have the issues I had prev. My version is v2.6.0