docker-gen exits with status code 2

[arcticShadow]

I've been pulling my hair out all night. As far as i can tell - running docker-gen as a container - the container should continue running. However, i have an intermitient situation where the container exits with status code 2.

when this happens, my config files are not being created..

this is the docker-compose file (with some omissions for privacy) - does it look right? It's essentially copied out of the examples with paths updates her and there.

version: '2'

services:
  node:
    # node image
    build: "docker-node"
    container_name: node
    volumes:
      - ./volumes/www:/data/app
    ports:
      - "3000:3000"
    environment:
      NODE_ENV: "development"
    working_dir: /data/app
    command: ["npm install; npm run develop"]

  nginx:
    image: nginx
    container_name: nginx
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - "/etc/nginx/conf.d"
      - "/etc/nginx/vhost.d"
      - "/usr/share/nginx/html"
      - "./volumes/proxy/certs:/etc/nginx/certs:ro"
    networks:
      - proxy-tier
  nginx-gen:
    image: jwilder/docker-gen
    container_name: nginx-gen
    depends_on:
      - letsencrypt-nginx-proxy-companion
      - simple-site
      - nginx
    volumes:
      - "/var/run/docker.sock:/tmp/docker.sock:ro"
      - "./volumes/proxy/templates/nginx-compose-v2.tmpl:/etc/docker-gen/templates/nginx.tmpl:ro"
    volumes_from:
      - nginx
    entrypoint: /usr/local/bin/docker-gen -notify-sighup nginx -watch -only-exposed -wait 30s:60s /etc/docker-gen/templates/nginx.tmpl /etc/nginx/conf.d/default.conf
  letsencrypt-nginx-proxy-companion:
    image: jrcs/letsencrypt-nginx-proxy-companion
    container_name: letsencrypt-nginx-proxy-companion
    volumes_from:
      - nginx
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
      - "./volumes/proxy/certs:/etc/nginx/certs:rw"
    environment:
      - NGINX_DOCKER_GEN_CONTAINER=nginx-gen

  simple-site:
    image: nginx
    container_name: simple-site
    depends_on:
      - letsencrypt-nginx-proxy-companion
    volumes:
      - "./volumes/nginx.conf/www/conf.d/:/etc/nginx/conf.d"
      - "./volumes/www/public:/usr/share/nginx/html"
    environment:
      - VIRTUAL_HOST=xxxxx
      - VIRTUAL_NETWORK=nginx-proxy
      - VIRTUAL_PORT=80
      - LETSENCRYPT_HOST=xxxxx
      - LETSENCRYPT_EMAIL=xxxxx
    networks:
      - proxy-tier

networks:
  proxy-tier:
    external:
      name: nginx-proxy

[ndanielsen]

I'm having a similar issue: nginx-gen | 2016/06/14 20:41:29 Unable to parse template: read /etc/docker-gen/templates/nginx.tmpl: is a directory

[dmitryint]

I'm having a similar problem. When I run the docker-compose up such a issue is not observed. But if I'm run docker-compose up -d the issue is present.

[arcticShadow]

I resolved my issue by changing the entrypoint to the default "/bin/sh -c" and moving the entrypoint command "docker-gen xxx" to the 'command'

The relevant docker-compose.yml snippet looks like:

nginx-gen:
    image: jwilder/docker-gen
    container_name: nginx-gen
    depends_on:
      - letsencrypt-nginx-proxy-companion
      - nginx
      - mailer
    volumes:
      - "/var/run/docker.sock:/tmp/docker.sock:ro"
      - "./volumes/proxy/templates/nginx-compose-v2.tmpl:/etc/docker-gen/templates/nginx.tmpl:ro"
    volumes_from:
      - nginx
    entrypoint: /bin/sh -c
    command: ["/usr/local/bin/docker-gen -notify-sighup nginx -only-exposed -watch -wait 30s:60s /etc/docker-gen/templates/nginx.tmpl /etc/nginx/conf.d/default.conf"]

[dmitryint]

It's worked for me too. Thanks @arcticShadow!

[arcticShadow]

Glad i could help.

[mvdstam]

@arcticShadow I've been having this same issue as well -- the docker-gen container seems to run fine for days until it's terminated randomly for some reason. I've used your fix regarding the change in entrypoint and CMD and so far, so good.

Could you explain why changing the entrypoint to /bin/sh (and thus running everything through shell) solves this issue? Isn't this some kind of deeper underlying issue we should deal with instead?

[viossat]

Same problem here. @arcticShadow's workaround works (why?) but it removes the graceful shutdown.

[arcticShadow]

I'm not sure why it happens. I haven't looked at this issue or the project i encountered it on in quite some time.

[olessavluk]

It looks like the problem is with the order in which containers are started. So just run: docker-compose up -d for the second time (without stopping containers) and everything should work fine

[murbanowicz]

I tried to use @arcticShadow solution but it doesn't work. 2017/02/15 21:50:03 Unable to parse template: read /etc/docker-gen/templates/nginx.tmpl: is a directory

[isaldarriaga]

@murbanowicz you should copy the volumes folder into your own project. otherwise docker compose will generate a folder with the name of the file you're trying to share to the container (/etc/docker-gen/templates/nginx.tmpl).

If this is the case, as soon as you copy the /etc/docker-gen/templates/nginx.tmpl, it will be parsed correctly.

[jebw]

I was able to reliably reproduce this - I was using the recommended setup for ngnix+letsecrypt+docker-gen containers - any attempt to restart docker resulted in the docker-gen container being stopped with an exit status of 2 - despite 'restart=always'

The recommended setup sets the container to always be the same - nginx-gen - I found removing the fixed name and using a label on the docker-gen container to identify the container instead seems to have solved the restart issue but I've no idea why ?

[Paike]

I also had the issue that docker-gen would not start occasionally after reboot. Took me some very long time. Changing the entrypoint to /bin/sh like @arcticShadow described seems to help.

[oddsund]

Please note that the entrypoint/cmd workaround seems to break the letsencrypt-nginx-proxy companion container. The SIGHUP signal sent from the companion to the nginx-proxy is received by the bash process, instead of the docker-gen process, and it does not seem like it's propagated through the bash process to the docker-gen process.

[arcticShadow]

I have noted that. Workaround. Every 2.5 months I manaukly kick the containers to restart them :-/ obviously this isn't the best solution. Would log to revisit this one day to find out what's really going on, or if this is still an issue.

[ghost]

@arcticShadow s solution worked for me. But first I had to delete the container with

    docker-compose down

Unfortunately the @thomaco appears :-( Is there any workaround?

[amc-nu]

I was having the same problem. Fixed with this: https://github.com/jwilder/docker-gen/issues/201#issuecomment-227990877

[abailly]

I tried the aforementioned workaround but I get the following error:

$ docker run --network rex-network --name nginx-gen --volumes-from nginx-proxy -v /tmp/nginx:/etc/nginx/conf.d -v /Users/arnaud/projects/env/nginx.tmpl:/etc/docker-gen/templates/nginx.tmpl:ro -v /var/run/docker.sock:/tmp/docker.sock:ro --label com.github.jrcs.letsencrypt_nginx_proxy_companion.docker_gen --entrypoint "/bin/sh" jwilder/docker-gen -c /usr/local/bin/docker-gen /usr/local/bin/docker-gen -notify-sighup nginx -wait 30s:60s /etc/docker-gen/templates/nginx.tmpl /etc/nginx/conf.d/default.conf
Usage: docker-gen [options] template [dest]

Generate files from docker container meta-data

Options:
  -config value
        config files with template directives. Config files will be merged if this option is specified multiple times. (default [])
  -endpoint string
        docker api endpoint (tcp|unix://..). Default unix:///var/run/docker.sock
  -include-stopped
        include stopped containers
  -interval int
        notify command interval (secs)
  -keep-blank-lines
        keep blank lines in the output file
...

ie. it seems it refuses to start when run within /bin/sh, however the exact same command-line arguments work fine when passed directly, without fiddling with the --entrypoint parameter.

[abailly]

It's only me being stupid and tired: the command line passed to /bin/sh -c has to be quoted. That said, it did not solve my issue: I redeployed the stack this morning and the container was still killed with signal 2 and I had to manually restart it.