4 ms·
> This was exactly what we were doing! we weren't using CMD in exec form, but in shell form. Changing this confirmed that gitlab-workhorse is now PID 1, and als
by pm90 4y ago
> This was exactly what we were doing! we weren't using CMD in exec form, but in shell form. Changing this confirmed that gitlab-workhorse is now PID 1, and also receives the termination signal after testing it locally
Do shells not forward signals correctly to their child processes? This seems surprising to me.
- js2 4y agoIt depends, and it's complicated. Here's bash's behavior: https://www.gnu.org/software/bash/manual/html_node/Signals.html https://www.gnu.org/software/bash/manual/html_node/Signals.h... I'm confused about this myself because I thought bash ignores SIGTERM only when it's interactive: https://www.gnu.org/software/bash/manual/html_node/Interactive-Shell-Behavior.html https://www.gnu.org/software/bash/manual/html_node/Interacti... In this case bash is not interactive, so I'm not sure why SIGTERM is ignored, but FWIW, the docker documentation explicitly says that it will: > The shell form prevents any CMD or run command line arguments from being used, but has the disadvantage that your ENTRYPOINT will be started as a subcommand of /bin/sh -c, which does not pass signals. This means that the executable will not be the container’s PID 1 - and will not receive Unix signals - so your executable will not receive a SIGTERM from docker stop <container>. https://docs.docker.com/engine/reference/builder/#cmd https://docs.docker.com/engine/reference/builder/#cmd The bash documentation for -c says nothing about different signal handling. POSIX mode doesn't address this behavior either.