-
Notifications
You must be signed in to change notification settings - Fork 5.3k
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
Labels
Comments
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
The |
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]>
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
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
in a terminal:
wait for echo servers to start up
In another terminal
Wait for container to stop. The
dev-echo1-1 exited with code 137
line is displayed in first terminal output as expectedError: 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
:Output of
docker info
:Additional environment details:
The text was updated successfully, but these errors were encountered: