basti1302
Repos
50
Followers
78
Following
1

Events

opened issue
[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, 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 (at least) from the behavior in 2.6.0.

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

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

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.

Compose Version

> 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_
                                    
Created at 3 days ago

chore: version 0.9.0.0

Created at 4 days ago
pull request closed
fix format for http header annotation
Created at 4 days ago
basti1302 delete branch fix-format-for-http-header-annotation
Created at 4 days ago

refactor(tracing): rename SDK.addAnnotationAt to addJsonValueAt

Also, fix the format of the span.data.http.header annotation. This was previously a JSON array of JSON arrays (representing each header as an array with two elements, name and value), which was incorrect. The correct format is a JSON object, using the header name as the key and the header value as the value.

Also, add more functions to add annotations to spans:

  • addAnnotationAt - now takes an Annotation value instead of arbitrary ToJSON types), the previous addAnnotationAt signature is still available as addJsonValueAt
  • addAnnotationToEntrySpan
  • addAnnotationToEntrySpanAt
  • addAnnotationValueToEntrySpanAt
  • addJsonValueToEntrySpanAt

BREAKING CHANGE: rename SDK.addAnnotationAt to addJsonValueAt

chore: remove stability field from cabal file

Created at 4 days ago
pull request opened
fix format for http header annotation
Created at 4 days ago

refactor(tracing): rename SDK.addAnnotationAt to addJsonValueAt

Also, fix the format of the span.data.http.header annotation. This was previously a JSON array of JSON arrays (representing each header as an array with two elements, name and value), which was incorrect. The correct format is a JSON object, using the header name as the key and the header value as the value.

Also, add more functions to add annotations to spans:

  • addAnnotationAt - now takes an Annotation value instead of arbitrary ToJSON types), the previous addAnnotationAt signature is still available as addJsonValueAt
  • addAnnotationToEntrySpan
  • addAnnotationToEntrySpanAt
  • addAnnotationValueToEntrySpanAt
  • addJsonValueToEntrySpanAt

BREAKING CHANGE: rename SDK.addAnnotationAt to addJsonValueAt

chore: remove stability field from cabal file

Created at 4 days ago
basti1302 create branch fix-format-for-http-header-annotation
Created at 4 days ago
delete branch
basti1302 delete branch fix/concourse-image-fetching
Created at 6 days ago

ci: added tag:latest to fix 404 image not found

refs https://github.com/concourse/registry-image-resource/issues/327

Created at 6 days ago
pull request closed
ci: added tag:latest to fix 404 image not found

refs https://github.com/concourse/registry-image-resource/issues/327

Created at 6 days ago

docs: add link to AHA for feature requests to github issue template

[skip ci]

Created at 1 week ago
delete branch
basti1302 delete branch link-to-aha-for-feature-requests
Created at 1 week ago
pull request closed
docs: add link to AHA for feature requests to github issue template
Created at 1 week ago
pull request opened
docs: add link to AHA for feature requests to github issue template
Created at 1 week ago
create branch
basti1302 create branch link-to-aha-for-feature-requests
Created at 1 week ago
issue comment
Typescript

Hi Rene, this would be a feature request. Please do not use Github issues for feature request (let alone old closed issues). Instead, please file these at https://automation-management.ideas.ibm.com/?project=INSTANA.

Actually, there is already a request for typescript definitions, so you can add your vote for this here: https://automation-management.ideas.ibm.com/ideas/INSTANA-I-300

Kind regards

Bastian

Created at 1 week ago