Proposal: don't stop containers when fig up exits

[dnephin]

With the current behaviour of fig up all container are stopped when a single container exits. This has caused some confusion.

• if a fig.yml contains any data volume containers (anything that would exit immediately) fig up is entirely useless, a -d must be specified every time
• if someone does a fig stop <some service> in a different terminal, it causes all containers to stop (which is not intuitive).

I propose the default for fig up change. Some ideas:

• default to -d, and provide a flag to allow the old behaviour
• default to tailing logs, but don't stop containers on or when any container stops, leave everything running.
• show a fig ps as the output after starting containers, to show that all containers have started properly (or not) (credit @thaJeztah)

I only ever use fig up with -d, and I wonder if others are using it this way. It seems like for CI you would have to, and for a development environment you may want to start/stop containers independently, so you'd still need -d.

[thaJeztah]

I only ever use fig up with -d

Just to chime in; I only use fig with -d, only very rarely use it without.

Breaking BC is unfortunate yes. Any thoughts how to not run in the background in the new situation? (-DFOREGROUND?) Should it be possible to set a default inside fig.yml?

[dnephin]

I was thinking, if there is support for this, of just waiting until the next major release, and breaking BC.

[thaJeztah]

I like it. I think it's less surprising (especially the "stopping" part). One nice addition (separate from this one) is to automatically show the output of fig ps after fig up is completed. That allows me to verify that all my containers are "up" and running.

[dnephin]

I like that, adding it to the list

[aanand]

Agreed that the current behaviour is a bit fiddly. I'm fine with the idea of not shutting down on Ctrl-C, I think - maybe instead we can output a message along the lines of:

^C
Exiting.
To re-attach, use `fig logs`.
To shut everything down, use `fig stop`.
To force shutdown, use `fig kill`.

As for defaulting to -d, less sold, but maybe we should do some user research there.

Finally, doing a ps at the end of fig up -d is an interesting idea, though I can foresee it causing confusion when people have containers that error out after a short time - depending on the order of events, fig ps might give them the false impression that everything's fine, when in reality one or more of their containers might be about to die.

[thaJeztah]

maybe we should do some user research there.

Sounds like a plan, I know docker did something like that some time ago, not sure how much response they got?

Also, still the option I mentioned in my first comment; specify wether or not the project should run background insidefig,yml

when in reality one or more of their containers might be about to die

Yes, that was something I wasn't sure of. Being able to verify is useful, especially for those cases. Was even thinking of having a "live" updating fig ps (if possible), but that would require user-input to dismiss it, so not sure if that's handy.

[anentropic]

+1 on this.... it is odd that fig up -d has different behaviour apart from just running in the background

is there a technical reason why it's not possible to make fig up (without -d) also not abort when your data container exits?

[aanand]

@anentropic that fig up stops all containers when a single container exits is a conscious design decision, not a technical limitation. The assumption is that most of the time, when developing an app, a single container exiting is an error that you want to investigate.

However, for the reasons @dnephin lists in the proposal, it's ended up being a bit confusing.

[anentropic]

@aanand I think it should behave the same re errors whether you -d or not and, as noted here, for some use cases the behaviour of -d mode is essential so I think fig should always work that way.

after all, if you don't use -d you get the logs in your console output, so you very easily see if there were any errors

[jbulchergist]

I like the idea of having fig up assume -d, although I don't feel strongly about it.

Otherwise, I believe that decoupling the behavior of fig stopping from the containers will lead to surprises itself and make fig less helpful for init scripts. Theoretically systemd should be able to handle it with separate start and stop scripts, but it is relatively more complicated...

As far as upstart goes (yes it's going away, but it's not gone yet), after several hours I still haven't gotten upstart to play nice with a start command of fig up -d --no-recreate and a stop command of fig stop. Upstart is unable to control the job and it's wasting my time.

Simply using a fig up --no-recreate and kill signal SIGINT fixes all of that instantly, and allows fig to really run containers as a service. I think that functionality (run containers as a service) is desirable in fig, and should be supported better (#756) rather than dropped. My mode of thinking is that I want to use fig as a service manager, and not a program for managing containers.

My two cents - people probably fall on both sides of the divide.

P.S. I have not experienced issues with fig up and data containers that exit right away. However, I can see how the behavior of fig stop <service name> is a cause for concern.

[sge-babrams]

I have been using it both ways and I agree with @dnephin that basically the most effective way for me so far has been to start things backgrounded and run fig logs as soon as they all start. Though honestly the only reason I do this is so that I can do things like bring down containers to do things like wipe a data container, simulate a container failure, etc as single container failure leads to full stack going down which is timely and unnecessary.

My 2 cents on how fig up should act:
fig up should have the functionality of -d in the sense that a single container dying should not bring down a whole stack but I think that auto attaching logs immediately should be the default and a switch to tell it not to.

[Starefossen]

Yes, please! docker-compose up should have the same behaviour as docker-compose up -d.

[pikeas]

+1 for -d by default and auto-attaching logs.

[dnephin]

Fixed #1754, will be in the 1.5 release, we went with the second option

[vanquangthanhhao]

You can't add "-ti" if you run docker by "docker run" command.
Or You add "tty: true "if you can by "docker compose" file
Reference :https://docs.docker.com/compose/compose-file/