This is to do with how docker signals the container.

When you run `docker stop ...`, some things will happen:

1. `docker` sends a `SIGTERM` to the main process of the container.
   The process is able to mask/ignore a `SIGTERM`, and if it does so (or handles it without terminating) "_nothing_" will happen.
1. After a timeout (default 10 seconds), `docker` sends a `SIGKILL` to the main process. This signal cannot be masked by a process, and thus it dies immediately with no opportunity for executing a shutdown prodedure.

Ideally, processes run within `docker` will respond to the `SIGTERM` in a timely fashion, taking care of any housekeeping before terminating.

If you know that the process either doesn't have any housekeeping to perform (e.g: `sleep`), or will not respond properly to `SIGTERM`, you can specify a shorter (or longer) timeout with the `-t` flag:

>     -t, --time=10
        Seconds to wait for stop before killing it

For example, in your case, you may like to run `docker stop -t 0 ${CONTAINER}`.

---

You can send a signal to the docker container using docker tools, for example:

    docker kill -s TERM kill-sleep

As we can see, this doesn't have the desired effect, whereas this does:

    docker kill -s KILL kill-sleep