docker stop does not stop the container gracefully. Instead after 10s (default) it gets SIGKILL and simply removed from memory by kernel.
This is because /bin/sh is PID 1 in the container which does not have an explicit handler for SIGTERM nor does it forward the signal to its child processes.
Is it for any reason I do not know? Is it for any reason better to SIGKILL the container?
Expected Behavior
Graceful stop of all processes in container.
Actual Behavior
Sudden kill of all processes no matter in which state they are.
Possible Fix
I would suggest something like dumb-init as ENTRYPOINT.
I can create a pull request with a proper PID 1 process (dumb-init, tini, pid1) optimized for container use.
As a side effect it may be possible to route SIGHUP to postfix master to reload changed config without restart.
Steps to Reproduce
docker stop your container and see exit code 137. (128 + 9[SIGKILL])
or
docker exec -ti YOUR_CONTAINER_NAME ps -ef and you see PID 1 is /bin/sh ...
docker stopdoes not stop the container gracefully. Instead after 10s (default) it gets SIGKILL and simply removed from memory by kernel.This is because
/bin/shis PID 1 in the container which does not have an explicit handler for SIGTERM nor does it forward the signal to its child processes.Is it for any reason I do not know? Is it for any reason better to SIGKILL the container?
Expected Behavior
Graceful stop of all processes in container.
Actual Behavior
Sudden kill of all processes no matter in which state they are.
Possible Fix
I would suggest something like dumb-init as ENTRYPOINT.
I can create a pull request with a proper PID 1 process (dumb-init, tini, pid1) optimized for container use.
As a side effect it may be possible to route SIGHUP to postfix master to reload changed config without restart.
Steps to Reproduce
docker stopyour container and see exit code 137. (128 + 9[SIGKILL])or
docker exec -ti YOUR_CONTAINER_NAME ps -efand you see PID 1 is/bin/sh ...