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.

[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.

[MicahZoltu]

I believe this should remain open. While it does seem low priority, I believe the current behavior is quite counter intuitive and arguably wrong.

[stale[bot]]

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

[ZukkyBaig]

Any update on this? Just noticed this behaviour, and containers are just left there bound to ports after integration tests are ran.

[Alexander-Shukaev]

Please, fix this bug.

[malcolm061990]

Is someone here to help us solving the problem?

[ndeloof]

IIUC the use-case reported on this issue, main reason to pass a service name to compose up is to select a subset of services to get logs. For this purpose, an alternative approach I proposed on https://github.com/docker/compose/issues/8546 is to define services to attach to, but compose up would still manage other services, and as such stop them on completion. wdyt?

[Dzoge]

You can disable logging on the specific containers container you don't want to see the logs for using:

logging:
    driver: none

and then start it up using

docker-compose up --build --exit-code-from tests --abort-on-container-exit tests db some-other-container

[ndeloof]

@Dzoge this hack won't work with Compose v2, which attach to containers (like docker run does) and does not rely on engine to collect logs

[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.

[MicahZoltu]

I believe this is still a problem, and many people are patiently following this issue waiting for it to be fixed.