`fig up` exits if container exits normally, but only first time

[anentropic]

I have the following fig.yml

nginx:
 image: anentropic/nginx
 links:
 - dpm
 ports:
 - "80:80"
 - "443:443"
 volumes_from:
 - nginxconf

nginxconf:
 image: anentropic/nginx_conf
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock:ro
 links:
 - uwsgi_app

nginxconf service CMD runs a script which queries the docker api in order to generate nginx conf for containers that need it, the script exits naturally with a code 0

problem I saw is the first time I fig up this happens:

anentropic_nginxconf_1 exited with code 0
Gracefully stopping... (press Ctrl+C again to force)
Stopping anentropic_nginx_1...
Stopping anentropic_dpm_1...
Stopping anentropic_postgres_1...

a bit annoying, but curiously if I do fig up again I see:

$ fig up
Recreating anentropic_postgresdata_1...
Recreating anentropic_postgres_1...
Recreating anentropic_uwsgi_app_1...
Recreating anentropic_nginxconf_1...
Recreating anentropic_nginx_1...
Attaching to anentropic_postgres_1, anentropic_uwsgi_app_1, anentropic_nginx_1
...

...this time everything stays up

Why is this?

Is there some way I should adapt either my nginx_conf image or my fig.yml to avoid needing to up twice?

[anentropic]

I switched this around so that the dependency is reversed (realised I was accidentally exposing the docker socket as a volume in the nginx container)

i.e

nginx:
 image: anentropic/nginx
 ports:
 - "80:80"
 - "443:443"
 # VOLUME /etc/nginx/sites-available
 # VOLUME /etc/nginx/sites-enabled
 # defined in Dockerfile

nginxconf:
 image: anentropic/nginx_conf
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock:ro
 volumes_from:
 - nginx
 links:
 - uwsgi_app

now when I fig up it fails every time:

anentropic_nginxconf_1 exited with code 0
Gracefully stopping... (press Ctrl+C again to force)
Stopping anentropic_nginx_1...
Stopping anentropic_dpm_1...
Stopping anentropic_postgres_1...

I'm not sure why it worked (albeit second time only) before, something to do with persistence of volumes I guess.

Possibly related to #613

[anentropic]

reading the discussion in #517 it sounds like my container should have some process that doesn't return, ie holds it open? or is there a better option for data-only container?

[dnephin]

That is correct, there needs to be a process running in the foreground.

[anentropic]

Is there a standard no-op process to use for this?

I saw elsewhere some have used - command: true in their fig.yml but in my case I need to run another script before the no-op so I don't want to override command

[dnephin]

Why do you want a container without a process?

I think what you want is to run nginx with daemon off http://nginx.org/en/docs/ngx_core_module.html, so that it stays in the foreground.

[anentropic]

This container doesn't run nginx, this one is basically a data-only container... I thought from the Docker docs it was quite acceptable to have one of those that exits with no process

In my case I wanted to run a script, to write out nginx conf files to a volume shared with the actual nginx container.

[dnephin]

Ah, I missed that. Yes it's ok to have a data-only container. I use echo or bash as the command.

I guess that just doesn't work with fig up. I always use fig up -d, so everything keeps running even if one exits.

You could also fig run nginxconf (or whatever container is the one that runs the script.

[anentropic]

I can't directly use echo or bash as the command because I need to run my script as the command
(how does that work anyway, if I $ echo in a terminal it returns immediately?)

thanks very much, fig up -d works fine!

[aanand]

Depending on the OS, you can use sleep infinity if you need the container to stay up for whatever reason.

[anentropic]

this would be fixed by #741

[thaJeztah]

@anentropic off-topic, but if you're looking for a way to automatically configure your NGINX, have a look at this project https://github.com/jwilder/nginx-proxy (and the software driving it: https://github.com/jwilder/docker-gen).

[dnephin]

Fixed by #1754, which will be in 1.5, and the race condition for grabbing containers in up was also previously fixed.