stop: The main process inside the container will receive SIGTERM, and after a grace period, SIGKILL. The first signal can be changed with the STOPSIGNAL instruction in the container’s Dockerfile, or the –stop-signal option to docker run.
kill: The main process inside the container is sent SIGKILL signal (default), or the signal that is specified with the –signal option. You can reference a container by its ID, ID-prefix, or name. When you want to send SIGHUP, there is the command
docker kill --signal=SIGHUP my_container.
You may notice that
The main process inside the container in both descriptions. What if we have
multiprocess in the container?
We could exec to watch the process.
docker exec -ti my-kill /bin/sh
We can get different results if we modify the entrypoint:
# Use `ENTRYPOINT ["node", "main.js"]`
# Use `ENTRYPOINT ["/run.sh"]`
When we use
ENTRYPOINT ["node", "main.js"], the
nodeprocess will receive the SIGTERM signal and close itself.
When we use
ENTRYPOINT ["/run.sh"], the
nodeprocess doesn’t get the proper signal, and it was forcibly shut down.
Well, we know what the offical description really means. It will only send
SIGTERM to the main process. If we have to use the script, we need to pass the signal to the child process.
Copy from program.sh(One one process):
Please refer to S6.
I want you to know that Docker doesn’t expected to run multiple processes within a single container, and I don’t encourage reader to write some weird scripts.
If you really need multiprocess support, please consider to use