fig up hangs when the container exits on startup

[SvenDowideit]

I thought I'd try using fig insteam of my usual Makefile, and played with @crosbymichael 's dsh: https://github.com/SvenDowideit/dsh/tree/go-dockerclient

it also hangs when setting the command: /bin/bash - i'm assuming that this is because you're not setting docker run -i to get stdin - I'm hoping you'll tell me there's a simple flag i didn't notice :)

(but having fig sit there when I can see that the container existed almost instantly is probably not really what is intended either)

[sven@t440s dsh]$ fig up
Recreating dsh_dsh_1...
Attaching to 


^CGracefully stopping... (press Ctrl+C again to force)

Aborting.
[sven@t440s dsh]$ fig --version
fig 1.0.0

[dnephin]

Hey Sven, I think there are a couple things here.

For interactive I think you want fig run dsh. fig up either goes into the background (with -d), or it goes into "log tailing".

There is also a bug here with fig up, which is probably what made this unintuitive. It should say 'Attaching to dsh` and print the stdout/stderr. I just noticed this today as well, it might be new.

I was able to fix the issue by removing the containers with fig rm --force. I believe the issue manifests when containers are recreated, but not when they're first created.

[dnephin]

Turns out the bug isn't related to recreate after all.

https://github.com/docker/fig/blob/1.0.0/fig/cli/main.py#L419

The list of containers to tail is fetched after running up, so if the container exits fast enough, nothing is returned. I guess this should either include stopped containers, or print a better message when it finds no containers.

Edit: Or even better, go back to getting the list of containers from the project.up() call, and use the new service.has_container() to filter it to the ones we want.

[SvenDowideit]

awesome! :) (for the fig run dsh tip :)

I really would prefer fig run to default to using the CMD/ENTRYPOINT - but 'new issue/pr' time for that :)

[baptistedonaux]

+1

[jkp]

I'm seeing this problem too - will this patch be merged to the mainline any time soon?

[dnephin]

My branch is missing some test cases, then it should be ready for a PR. Not sure when I'll be able to get to that.

[dnephin]

Fixed by #1645, I realize now why I thought I had fixed it already. I never submitted a PR for fbd0a6a which addressed the filtering issue of #1858