compose: abort-on-container-exit not working if a service is given
Hi everybody,
Is it normal that abort-on-container-exit option of the up command is not working if a service is given for example: docker-compose up --abort-on-container-exit web doesn’t stop the db service if the web service stops, whereas docker-compose up --abort-on-container-exit stops it
version: ‘2’
services:
db:
image: postgres:9.3
web:
build: ./
links:
- db
Client: Version: 1.12.1 API version: 1.24 Go version: go1.6.3 Git commit: 23cf638 Built: Thu Aug 18 05:22:43 2016 OS/Arch: linux/amd64
Server: Version: 1.12.1 API version: 1.24 Go version: go1.6.3 Git commit: 23cf638 Built: Thu Aug 18 05:22:43 2016 OS/Arch: linux/amd64
docker-compose version 1.8.0, build f3628c7 docker-py version: 1.9.0 CPython version: 2.7.9 OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Reactions: 9
- Comments: 36
Can I please have an update on this? It is counter-intuitive to me to not stop containers listed in
depends_on.Please, fix this bug.
I see what you are getting at @shin-, that when you explicitly start a service you aren’t saying anything about the other services in the
docker-compose.ymlfile, and so it might be counterintuitive to change the state of any services that Docker Compose didn’t start.But it also seems counterintuitive to not stop any services that were started as a consequence of using
depends_on. It completely threw me that secondary containers weren’t being shut down once integration tests were complete.Any thoughts on that aspect?
Hi Shin, Thanks for the answer. In my view --abort-on-container-exit should work as long as linked containers are started. If I give a service like web in param, by default linked services are also started and I think that --abort-on-container-exit should by default stopped these services. What I wanna do is to put two différent configurations of a service in the compose file (web1 and web2 for example), and i can precise one of the service if i want to separately start it with its linked containers.
Not sure if my use case is exactly the same, but I’d like to specify a single service which causes the others to stop when it exits.
I have a container that runs integration tests and it’s only that one that I’d like to stop everything, as there are other containers that run database migrations etc. that may exit first. If they exit first then my integration tests don’t complete their run.
Any update on this? Just noticed this behaviour, and containers are just left there bound to ports after integration tests are ran.
We also are running into problems with this. We are using
docker-composefor integration testing and so we dodocker-compose up ... test app_under_test. This will allow us to see the console output forapp_under_testandtestbut it won’t show us the massive spam of output from our dependencies like MySQL, Zookeeper, Kafka, etc. which in almost all cases we don’t care about, isn’t under our control, and is very noisy.However, after the
testcontainer exits only theapp_under_testalso exits, which leaves all of the dependencies running indefinitely even though they are no longer used. They just sit there consuming resources and (in some cases) bound to ports.@shin- Can you help me understand the scenario under which you believe the current behavior is correct? To me, a
docker-composecollection is a single contiguous unit. Presumably they would all come and go together in most cases. Is that not how you usedocker-compose? Is that not howdocker-composeis intended to be used?I believe this is still a problem, and many people are patiently following this issue waiting for it to be fixed.
@Dzoge this hack won’t work with Compose v2, which attach to containers (like
docker rundoes) and does not rely on engine to collect logsI believe this should remain open. While it does seem low priority, I believe the current behavior is quite counter intuitive and arguably wrong.