Compose: abort-on-container-exit not working if a service is given

[fchennouf]

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

[shin-]

Hi!

I believe that is the expected behavior, yes. The command you're running docker-compose up [...] web is explicit about handling the web service, and not any other - having it stop the db service, which as far as compose is concerned is running independently, would seem very counter-intuitive to me. Is there a specific reason why you need to do things that way?

[fchennouf]

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.

[MicahZoltu]

We also are running into problems with this. We are using docker-compose for integration testing and so we do docker-compose up ... test app_under_test. This will allow us to see the console output for app_under_test and test but 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 test container exits only the app_under_test also 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-compose collection is a single contiguous unit. Presumably they would all come and go together in most cases. Is that not how you use docker-compose? Is that not how docker-compose is intended to be used?

[ronin1]

We actually have the same need for our integration test in CI. We only care about our application container (where we have the app). Sometimes the tests are run directly on the application container, sometimes we run it on a separate test container and if the test pass or fail, we would like to tear down all containers. Is there an easy way to do this with docker-compose?

[markbirbeck]

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.yml file, 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?

[amithgeorge]

Any updates on this? Same use-case. Same issue.

[chris-vest]

Could also use a solution here... Three containers in my compose, want to abort upon any one of them exiting. However services stay up, flag doesn't actually seem to have any effect?

[GraemeF]

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.

[MicahZoltu]

@GraemeF Assuming you have your dependencies setup correctly in docker-compose.yml, then you can just do docker-compose up integration-tests --abort-on-container-exit and I _believe_ that will do what you want and only terminate the docker-compose execution if integration-tests service exits. If any of the things that integration-tests depends on exits, I _think_ it will keep running.

[GraemeF]

Thanks @MicahZoltu - I just spent some time experimenting with that and, unfortunately, the dependencies are left running afterwards which isn't ideal for my scenario. Nice idea though 😄

[MicahZoltu]

Hmm, I just tested this again and I am witnessing the same behavior, the dependency containers are not exited when the primary container is with --abort-on-container-exit. However, if I don't specify a service (e.g., just docker-compose up --abort-on-container-exit) then all of the containers exit. Maybe I'm just mis-remembering how this used to work? 😢

[fasmat]

I'm also running into this problem.

We try to use docker-compose for our integration testing and after all test finish and the "main" container exits, it's dependencies are still running even when --abort-on-container-exit is set.

[damtur]

Can I please have an update on this? It is counter-intuitive to me to not stop containers listed in depends_on.

[Alqio]

Any updates on this?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as not stale anymore due to the recent activity.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[KevinGrandon]

Fixing this functionality would be super nice. Right now it seems like a bug.

[stale[bot]]

This issue has been automatically marked as not stale anymore due to the recent activity.