[BUG] Ctrl+C on docker-compose up stops all containers of the same project instead of only the ones started via up 

### Description

When starting multiple services in different shells 
* via `docker-compose -f ... up`,
* with an identical project name, 
* without providing a specific service name,
* then terminating _one_ of the docker-compose processes will terminate _all_ services in that project.
 
This is a difference to 1.x behavior and also different to the behavior of various versions between 2.6.0-2.9.0 The behavior has been introduced in 2.10.0. (See below for which versions I tested.)

This is on MacOS Monterey 12.6 with Docker Desktop 4.10.0 (82025).

The following issues might be related (albeit being different issues when you look at the details):

* #9287 -- this one is really similar, but seems to be related to containers being in the same network; according to the issue it was fixed in 2.6.0, so this issue here might be a regression
    * I've also tested this with 2.6.0 and it still works there, so this regression must have happened between 2.6.0 and 2.13.0
* #9696 -- this but was related to `depends_on`, which is not used here

### Tested `docker-compose` Versions

- 1.29.2: works as expected
- 2.6.0: works as expected
- 2.9.0: works as expected
- 2.10.0: broken
- 2.10.1: broken
- 2.12.x: broken
- 2.13.0: broken

So this changed between 2.9.0 and 2.10.0.

Of course, chances are that this change in behavior was intentional, but there is nothing in the 2.10.0 release notes that sounds related to this.

### Steps To Reproduce

memcached.yaml:
```
version: '3'
services:

  memcached:
    image: memcached
```

redis.yaml
```
version: '3'
services:

  redis:
    image: redis
```

In the first shell:
```
docker-compose -f redis.yaml up

WARN[0000] Found orphan containers ([docker-compose-ctrl-c-repro-memcached-1]) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.
[+] Running 1/0
 ⠿ Container docker-compose-ctrl-c-repro-redis-1  C...                                                 0.0s
Attaching to docker-compose-ctrl-c-repro-redis-1
docker-compose-ctrl-c-repro-redis-1  | 1:C 25 Nov 2022 06:16:42.615 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
[...] redacted irrelevant logs from Redis starting up
docker-compose-ctrl-c-repro-redis-1  | 1:M 25 Nov 2022 06:16:42.616 * Ready to accept connections
```

In a second shell:
```
docker-compose -f memcached.yaml up
WARN[0000] Found orphan containers ([docker-compose-ctrl-c-repro-redis-1]) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.
[+] Running 1/0
 ⠿ Container docker-compose-ctrl-c-repro-memcached-1  Created                                          0.0s
Attaching to docker-compose-ctrl-c-repro-memcached-1
```

Press CTRL+C in the first shell running Redis:

```
	^CGracefully stopping... (press Ctrl+C again to force)
[+] Running 0/0
 ⠋ Container docker-compose-ctrl-c-repro-redis-1      Stopping                                         0.1s
 ⠋ Container docker-compose-ctrl-c-repro-memcached-1  Stopping                                         0.1s
canceled
``` 

^ Note that docker-compose explicitly says that it is stopping `docker-compose-ctrl-c-repro-memcached-1` as well. (All of this happens in a folder named docker-compose-ctrl-c-repro, so this becomes the default docker compose project name.)

This will then happen in the second shell:

```
docker-compose-ctrl-c-repro-memcached-1  | Signal handled: Terminated.
docker-compose-ctrl-c-repro-memcached-1 exited with code 0
```

On other occasions I have also observed other exit codes, I believe that depends on how the executable running in the container handles the `SIGTERM` (?) signal. 

----

### Using a Custom Project Name

The behavior is the same when using a custom project name, as long as the project name is identical for both services. That is, when started via `docker-compose -f redis.yaml -p project up` and `docker-compose -f memcached.yaml -p project up`, the behavior does not change.

Using two different project names changes the behavior and can be used as a workaround:

* Start the first service with `docker-compose -f redis.yaml -p project-1 up`
* Start the second service with `docker-compose -f memcached.yaml -p project-2 up`
* Terminate the first service with CTRL+C
* Then this is the outcome in the first shell:

```
^CGracefully stopping... (press Ctrl+C again to force)
[+] Running 1/1
 ⠿ Container project-1-redis-1  Stopped                                                                0.3s
canceled
```
^ it does not mention the memcache service; the memcache service stays up.

### When Providing the Service Name Explicitly

This does not happen when the *service name* is provided explicitly to `docker-compose up`. This is another possible workaround:

* Start the first service with `docker-compose -f redis.yaml up redis`
* Start the second service with `docker-compose -f memcached.yaml up memcached`
* Terminate the first service with CTRL+C
* Then this is the outcome in the first shell:

```
^CGracefully stopping... (press Ctrl+C again to force)
[+] Running 1/1
 ⠿ Container docker-compose-ctrl-c-repro-redis-1  Stopped                                                      0.2s
canceled
```
^ it does not mention the memcache service; the memcache service stays up.

### In docker-compose v1 and older v2 versions

I have tested this with v1 (docker-compose version 1.29.2, build 5becea4c), the behavior is different there.

* first shell: `/usr/local/bin/docker-compose-v1 -f redis.yaml up`
* second shell: `/usr/local/bin/docker-compose-v1 -f memcached.yaml up` 
* Terminate the first shell with CTRL+C
* Output:
```
^CGracefully stopping... (press Ctrl+C again to force)
Stopping docker-compose-ctrl-c-repro_redis_1 ... done
```
* The memcache service stays up.

Same for 2.6.0 - 2.9.0. I didn't test 2.x versions older than 2.6.

### Compose Version

```Text
> docker-compose version
Docker Compose version 2.13.0
> docker compose version
Docker Compose version 2.13.0
```
```


### Docker Environment

```Text
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc., v0.8.2)
  compose: Docker Compose (Docker Inc., 2.13.0)
  extension: Manages Docker extensions (Docker Inc., v0.2.7)
  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: 10
  Running: 0
  Paused: 0
  Stopped: 10
 Images: 124
 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: 8
 Total Memory: 15.64GiB
 Name: docker-desktop
 ID: YGZ2:ZHMQ:QWW5:N762:4S4E:UMKP:VVEL:GPLS:IZYA:EEX7:RQ65:E2ST
 Docker Root Dir: /var/lib/docker
 Debug Mode: true
  File Descriptors: 55
  Goroutines: 63
  System Time: 2022-11-25T06:10:48.828041964Z
  EventsListeners: 9
 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
```
```


### Anything else?

_No response_

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[BUG] Ctrl+C on docker-compose up stops all containers of the same project instead of only the ones started via up #10022

Description

Tested `docker-compose` Versions

Steps To Reproduce

Using a Custom Project Name

When Providing the Service Name Explicitly

In docker-compose v1 and older v2 versions

Compose Version

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[BUG] Ctrl+C on docker-compose up stops all containers of the same project instead of only the ones started via up #10022

Description

Description

Tested docker-compose Versions

Steps To Reproduce

Using a Custom Project Name

When Providing the Service Name Explicitly

In docker-compose v1 and older v2 versions

Compose Version

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Tested `docker-compose` Versions