Docker Community Forums

Share and learn in the Docker community.

Specify Internal Command when a Container is Stopped


(Laurent Magnin) #1

It would be helpful to be able to specify an internal command that should be called before a container is stopped.

With “classic” Docker, it is always possible to first perform a docker exec [my command] on a container before stopping it. Which is not possible with containers handled by Services when the numbers of replicas are decreased.

That instruction should be declared the same way as the CMD one (in the Dockerfile, docker-compose, CLI, etc.).

The “–time int Seconds to wait for stop before killing it (default 10)” parameter should also be available through the configuration files to allow sufficient time to that command to succeed.


(David Maze) #2

What’s an example?

docker stop works by sending normal Unix signals (SIGTERM, then SIGKILL) that the process can catch and respond to. If you’re dealing with something, like Apache, that wants to keep a pid file, that you’re storing in a persistent volume (because it’s in the same directory as the logs), it should (and usually does) react to the SIGTERM by deleting its own pid file.

(This is probably deemphasized in large part because the container filesystem is going away, in much the same way that most C programs don’t bother to free() all of their memory at the end of their main() function because the process is about to exit anyways.)

That post in fact covers the existing options pretty well; the one thing I’d add to it is that if you’re running an ENTRYPOINT script, that runs as pid 1; if it ends with a shell exec statement then the CMD takes over as pid 1 and if it doesn’t then the shell wrapper needs to handle signals; but this also means that ENTRYPOINT could be a place to handle any cleanup that needs to happen after the container exits.

(Laurent Magnin) #3

An example?

To create a Spark Cluster, we could use the sbin/ script to start… the slaves.
It would be nice to be able to do the opposite by calling the existing sbin/ script before stopping a slave container.

I understand that we might create a main process that would do the same when it intercepts the SIGTERM, but that would be more complex to set than specifying something like STOP_CMD sbin/ in the Dockerfile…

Also, defining the timeout issue when using Service still remains with the existing framework.