Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Signals not handled properly #12

Closed
robbertkl opened this issue Oct 13, 2015 · 2 comments
Closed

Signals not handled properly #12

robbertkl opened this issue Oct 13, 2015 · 2 comments

Comments

@robbertkl
Copy link

Running supervisord within dockerize I've noticed the following issues:

When dockerize receives SIGINT (e.g. ctrl-c in an interactive docker container) the following happens:

  • dockerize outputs Received signal: interrupt
  • dockerize forwards this signal to its child process (supervisord in my case)
  • supervisord gracefully terminates its "programs" and exits
  • dockerize outputs Command finished successfully.
  • (so far so good, now for the unexpected)
  • dockerize doesn't exit
  • after 10 seconds, dockerize outputs Killing command due to timeout. and exits

Seems to me the 10 second wait has no function, the child process is already gone (which dockerize noticed) and dockerize should exit right away.

Another issue occurs when dockerize receives SIGTERM (e.g. on docker stop):

  • dockerize exits immediately without any output
  • signal is not forwarded to child process (supervisord) and not waited on
  • supervisord (and its running "programs") don't get a chance to gracefully shutdown
  • actually the child process (supervisord and its children) is not killed at all and keeps running; however, the container is destroyed along with any processes in it, similar to a SIGKILL to those processes (unclean shutdown)

In contrast, when supervisord receives SIGTERM, it forwards this to its running programs and waits for them to exit cleanly, killing them with SIGKILL if it takes too long. IMO dockerize should do something similar.

@jwilder
Copy link
Owner

jwilder commented Oct 27, 2015

@robbertkl The timeout should be fixed in v0.0.4. The SIGTERM/SIGKILL handling should also be fixed, but you need to make sure your Dockerfile CMD is using the exec form;

CMD ["dockerize", "-template", ...]

vs.

CMD dockerize -template ....

The latter actually invokes /bin/sh dockerize which will not forward signals to dockerize correctly. You can run docker exec <container> ps -ef to see if dockerize is actually pid 1 or if /bin/sh is.

@jwilder jwilder closed this as completed Oct 27, 2015
@robbertkl
Copy link
Author

Yes, I'm aware of the exec form (and the consequences). Awesome job on the improvements / fixes, I'll give them a spin soon!

apollo13 pushed a commit to apollo13/dockerize that referenced this issue Dec 30, 2018
lsago added a commit to MaastrichtUniversity/docker-dev that referenced this issue Mar 3, 2022
Why?

To speed up `docker-compose down` or `docker-compose stop`.. If
dockerize gets the stop signal (SIGTERM), it will act accordingly and
stop the process. But if the shell[1] gets the signal (result of having CMD
in "shell form"), the signal will be ignored (also not forwarded to
dockerize). 10 seconds later docker will force stop the container.

See: jwilder/dockerize#12
     https://docs.docker.com/engine/reference/builder/#cmd

Note that as centos has bash for /bin/sh, this is not necessary. But
it's converted anyway for consistency. See comment at the end of its
Dockerfile.

Also note that for iCAT, avoiding this 10 second timeout is done
differently, as it doesn't run dockerize. See comments in its
bootstrap.sh for more details (irods/icat/scripts/bootstrap.sh)

[1]: As long as the shell is 'dash' it seems, as it's the case for
     ubuntu images. Bash behaves differently (centos)

[DHDO-163]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants