Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Removing a stopped container stop "docker compose up" in attached mode with error #8747

Closed
fabien-michel opened this issue Oct 4, 2021 · 2 comments · Fixed by #8859
Closed
Labels

Comments

@fabien-michel
Copy link

fabien-michel commented Oct 4, 2021

Description

Since recent upgrade to docker compose v2.0 . The "up" command in attached mode (without the --detach flag) stop and detach when a single container is stopped then removed.
The others containers keep running.

Steps to reproduce the issue:
1.
docker-compose.yaml

version: '2'
services:
  echo1:
    image: k8s.gcr.io/echoserver:1.10
    ports:
      - "8081:8000"     
  echo2:
    image: k8s.gcr.io/echoserver:1.10
    ports:
      - "8082:8000"

in a terminal:

docker compose up

wait for echo servers to start up

In another terminal

docker compose stop echo1

Wait for container to stop. The dev-echo1-1 exited with code 137 line is displayed in first terminal output as expected

docker compose rm -f echo1

Error: No such container: 13c269abd727d3817c1436d9e3...
is displayed in first terminal output and the attach is lost.

Describe the results you received:
The following error is displayed in first terminal:
Error: No such container: 13c269abd727d3817c1436d9e3...

And the attach is lost.

Describe the results you expected:
Output should stay attached to others containers, and reattached to the container echo1 when it is run again.
This is the results with docker-compose v1

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker compose version:

Docker Compose version 2.0.1

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Build with BuildKit (Docker Inc., v0.6.1-docker)
  compose: Docker Compose (Docker Inc., 2.0.1)

Server:
 Containers: 35
  Running: 5
  Paused: 0
  Stopped: 30
 Images: 158
 Server Version: 20.10.8
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: false
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 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: 72cec4be58a9eb6b2910f5d10f1c01ca47d231c0.m
 runc version: v1.0.2-0-g52b36a2d
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.14.8-arch1-1
 Operating System: Arch Linux
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 21.43GiB
 Name: ***
 ID: HQFE:7V3Y:2HBU:FGTM:QLXY:XG2Q:IN2W:NNZY:4CLH:K5EU:HMHA:VVL4
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Additional environment details:

@fabien-michel fabien-michel changed the title Removing a stopped container stop docker compose up in attached mode with Error Removing a stopped container stop "docker compose up" in attached mode with error Oct 4, 2021
@sdt
Copy link
Contributor

sdt commented Oct 30, 2021

docker-compose logs -f suffers the same problem.

  1. Run docker-compose up like step 2 above
  2. In another terminal run docker-compose logs -f
  3. Stop and remove a service like step 3 above

The logs -f command will exit with the same message that up exits with.

sdt added a commit to sdt/compose that referenced this issue Oct 30, 2021
Fixes docker#8747

When the event is a container destroy, calling ContainerInspect returns
an error, because the container no longer exists. This causes both
`docker-compose up` and `docker-compose logs -f` to exit when removing a
stopped container.

This is handled in a similar manner to the container die case further
down. Not sure if this case also needs the call to `listener(...)`.

Signed-off-by: Stephen Thirlwall <[email protected]>
sdt added a commit to sdt/compose that referenced this issue Oct 31, 2021
Fixes docker#8747

When the event is a container destroy, calling ContainerInspect returns
an error, because the container no longer exists. This causes both
`docker-compose up` and `docker-compose logs -f` to exit when removing a
stopped container.

This container has already emitted its die event, and has already been
cleanup up. I believe all that needs doing in this case is to ignore the
error. Another approach might be to check for the destroy event before
calling ContainerInspect.

Signed-off-by: Stephen Thirlwall <[email protected]>
sdt added a commit to sdt/compose that referenced this issue Oct 31, 2021
Fixes docker#8747

When the event is a container destroy, calling ContainerInspect returns
an error, because the container no longer exists. This causes both
`docker-compose up` and `docker-compose logs -f` to exit when removing a
stopped container.

This container has already emitted its die event, and has already been
cleanup up. I believe all that needs doing in this case is to ignore the
error. Another approach might be to check for the destroy event before
calling ContainerInspect.

Signed-off-by: Stephen Thirlwall <[email protected]>
sdt added a commit to sdt/compose that referenced this issue Oct 31, 2021
Fixes docker#8747

When the event is a container destroy, calling ContainerInspect returns
an error, because the container no longer exists. This causes both
`docker-compose up` and `docker-compose logs -f` to exit when removing a
stopped container.

This container has already emitted its die event, and has already been
cleaned up. I believe all that needs doing in this case is to early-out.

Signed-off-by: Stephen Thirlwall <[email protected]>
ndeloof pushed a commit that referenced this issue Nov 4, 2021
Fixes #8747

When the event is a container destroy, calling ContainerInspect returns
an error, because the container no longer exists. This causes both
`docker-compose up` and `docker-compose logs -f` to exit when removing a
stopped container.

This container has already emitted its die event, and has already been
cleaned up. I believe all that needs doing in this case is to early-out.

Signed-off-by: Stephen Thirlwall <[email protected]>
@fabien-michel
Copy link
Author

Do not occur for me with recent versions. (v 2.2.2)

debdutdeb pushed a commit to debdutdeb/compose that referenced this issue Jun 30, 2022
Fixes docker#8747

When the event is a container destroy, calling ContainerInspect returns
an error, because the container no longer exists. This causes both
`docker-compose up` and `docker-compose logs -f` to exit when removing a
stopped container.

This container has already emitted its die event, and has already been
cleaned up. I believe all that needs doing in this case is to early-out.

Signed-off-by: Stephen Thirlwall <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants