CTRL+C always stops all running container

[ChristopherZhong]

Description

There is a difference in behaviour in CTRL+C between Docker Compose V1 and V2.
I came across the issue #9287 but I think this situation is not the same.

In Docker Compose V1, CTRL+C stops all services if the up command is used without specifying any services.
If the up command is provided with the name of the service(s), it only stops the given service(s).

However, in Docker Compose V2, CTRL+C always stops all services regardless if the up command is provided with the name of service(s).

Given a sample docker-compose.yml file.

services:
  app:
    depends_on:
      - database
    image: nginx

  database:
    environment:
      POSTGRES_PASSWORD: password
    image: postgres

Steps to reproduce the issue:

1. Run docker-compose up app
2. Press CTRL+C
3. Run docker compose up app
4. Press CTRL+C

Describe the results you received:

Both app and database services stopped.

Describe the results you expected:

Only the app service is stopped.

Output of docker compose version:

Docker Compose version v2.7.0

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.7.0)
  extension: Manages Docker extensions (Docker Inc., v0.2.8)
  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: 7
  Running: 3
  Paused: 0
  Stopped: 4
 Images: 12
 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: 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: 10c12954828e7c7c9b6e0ea9b0c02b01407d3ae1
 runc version: v1.1.2-0-ga916309
 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: 3.842GiB
 Name: docker-desktop
 ID: YOUK:I7PD:H5YN:LLQ4:XP2V:W2Y5:LGE5:SCQ4:5SLU:KSKG:JS3R:HXCI
 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:

[milas]

It looks like this is related to depends_on.

For example, consider the following (using example from issue):

$ docker compose up -d database
[+] Running 1/1
 ⠿ Container ctrlc-database-1  Started

$ docker compose up app
[+] Running 2/0
 ⠿ Container ctrlc-database-1  Running                                                                                                         0.0s
 ⠿ Container ctrlc-app-1       Created
...

# hit ctrl-c
^CGracefully stopping... (press Ctrl+C again to force)
[+] Running 0/0
 ⠋ Container ctrlc-app-1  Stopping                                                                                                             0.1s
canceled

$ docker compose ps
docker compose ps
NAME                COMMAND                  SERVICE             STATUS              PORTS
ctrlc-app-1         "/docker-entrypoint.…"   app                 exited (0)
ctrlc-database-1    "docker-entrypoint.s…"   database            exited (0)

The database got killed even though

1. Compose did not say it was terminating it!
2. It wasn't launched even implicitly by this compose up session

---

The case as described in the original issue is a bit murkier - I'm not sure what the right behavior here is! If you compose up app and that brings up database as a result, should Ctrl-C remove both? I'd probably argue we should maintain parity with v1 and NOT stop database. If we want to offer that behavior (stop implicitly launched dependencies on Ctrl-C), a new flag is probably a good option.

[milas]

#9701 includes a fix that will be included in the next Compose release.

If you docker compose up app and it launches database, when you hit Ctrl-C, only app will be stopped, which matches the behavior in v1 as well as older versions of v2 before this regressed.

Thanks for the bug report and repro steps!