What's the difference between docker stop and docker kill?

Afaik, both will stop a running container. Is it that docker stop attempts to stop the process run inside the container in the correct way, while docker kill will send a kill signal? If so how would docker stop know how to correctly stop the running process. (Since this differs from process to process)

up vote 82 down vote accepted

Is it that docker stop attempts to stop the process run inside the container in the correct way, while docker kill will send a kill signal?

Basically yes, the difference is subtle, but outlined in the Command Line reference:

  • docker stop: Stop a running container (send SIGTERM, and then SIGKILL after grace period) [...] The main process inside the container will receive SIGTERM, and after a grace period, SIGKILL. [emphasis mine]
  • docker kill: Kill a running container (send SIGKILL, or specified signal) [...] The main process inside the container will be sent SIGKILL, or any signal specified with option --signal. [emphasis mine]

So stop attempts to trigger a graceful shutdown by sending the standard POSIX signal SIGTERM, whereas killjust kills the process by default (but also allows to send any other signal):

The SIGTERM signal is sent to a process to request its termination. Unlike the SIGKILL signal, it can be caught and interpreted or ignored by the process. This allows the process to perform nice termination releasing resources and saving state if appropriate. It should be noted that SIGINT is nearly identical to SIGTERM.

While not enforced in anyway, processes are generally expected to handle SIGTERM gracefully and do the right thing depending on their responsibilities - this can easily fail due to the graceful shutdown attempt taking longer than the grace period though, which is something to consider if data integrity is paramount (e.g. for databases); see e.g. Major Hayden's SIGTERM vs. SIGKILL for a more detailed explanation:

The application can determine what it wants to do once a SIGTERM is received. While most applications will clean up their resources and stop, some may not. An application may be configured to do something completely different when a SIGTERM is received. Also, if the application is in a bad state, such as waiting for disk I/O, it may not be able to act on the signal that was sent.

  • 1
    So if I wanted to have a generic shutdown procedure for containers, I would have to catch the SIGTERM in the supervisor/runit process? – CMCDragonkai Aug 15 '14 at 9:01
  • What's the best practice here? I understand why we would use docker kill by hand to save some time during shutdown, but in a script, wouldn't it always better to attempt a graceful shutdown via docker stop? I'm still seeing lots of docker kills in scripts though. – Dennis Jun 26 at 16:52

docker kill will stop the main entrypoint process/program abruptly

docker stop will try to stop it gracefully (will ask politely :P)

in both cases the filesystem changes will be persisted (at the time of stop or kill) so if you docker start <container> then it will continue from there.

  • 1
    ...but in case of docker kill any pending file system changes that the main process still had in memory will be lost, so the file system might end up damaged? – Arjan Apr 29 '17 at 14:35
  • obviously , since is an abrupt stop, only changes at the time of kill will be persisted. Anything pending will be lost. My point was that docker kill is not really... killing the container, its stopping the process. like when you power off your computer instead of shutting down – awkwardarts Apr 30 '17 at 8:11

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.