"Docker stop" sends a SIGTERM to pid 1 inside container. But it is not propagated to supervisord root process. So docker stop command takes 10 sec which is the default docker timeout before sending SIGKILL. And SIGKILL does not let any chance to supervisor managed services to exit cleanly.
This behavior is easy to reproduce :
docker exec -it soulseek /bin/bash
kill -TERM 1
Nothing happens.
But if we send a SIGTERM to the pid of supervisord, then all services are stopped and the container exits immediatly.
If we check the docker logs, we can see this :
2022-10-08 14:42:10,645 WARN received SIGTERM indicating exit request
2022-10-08 14:42:10,655 INFO waiting for tigervnc, openbox, novnc, soulseek to die
2022-10-08 14:42:10,662 INFO stopped: soulseek (terminated by SIGTERM)
2022-10-08 14:42:10,680 INFO stopped: novnc (exit status 143)
2022-10-08 14:42:10,727 INFO stopped: openbox (exit status 0)
2022-10-08 14:42:10,817 INFO stopped: tigervnc (exit status 0)
Solution : supervisord should be ran with "exec" command, which purpose is to replace init.sh process by supervisord process.
When we do that, docker stop works like a charm.
"Docker stop" sends a SIGTERM to pid 1 inside container. But it is not propagated to supervisord root process. So docker stop command takes 10 sec which is the default docker timeout before sending SIGKILL. And SIGKILL does not let any chance to supervisor managed services to exit cleanly.
This behavior is easy to reproduce :
Nothing happens. But if we send a SIGTERM to the pid of supervisord, then all services are stopped and the container exits immediatly. If we check the docker logs, we can see this :
Solution : supervisord should be ran with "exec" command, which purpose is to replace init.sh process by supervisord process. When we do that, docker stop works like a charm.
Before using exec :
After using exec :
PR coming...