-
Notifications
You must be signed in to change notification settings - Fork 415
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
Comments
@robbertkl The timeout should be fixed in
vs.
The latter actually invokes |
Yes, I'm aware of the exec form (and the consequences). Awesome job on the improvements / fixes, I'll give them a spin soon! |
fix: -version report unknown
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]
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:Received signal: interrupt
Command finished successfully.
Killing command due to timeout.
and exitsSeems 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):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 withSIGKILL
if it takes too long. IMO dockerize should do something similar.The text was updated successfully, but these errors were encountered: