This is to do with how docker signals the container.

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

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

Now let's handle the SIGTERM. Backgrounding and waiting for sleep are due to how bash handles signals (see this for more).

Now let's handle the SIGTERM. Backgrounding and waiting for sleep are due to how a POSIX shell handles signals (see this for more).

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

However, when running with PID = 1, unhandled signals are ignored.

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

However, when running with PID = 1, unhandled signals are ignored, otherwise you'd end up with a kernel panic:

Kernel panic - not syncing: Attempted to kill init!

An Experiment

Dockerfile

FROM busybox
COPY run.sh /run.sh
RUN chmod +x /run.sh
CMD "/run.sh"

run.sh

#!/bin/sh

echo "sleeping"
sleep 100000

Now, run

docker build -t kill-sleep .
docker run --rm --name kill-sleep kill-sleep

And this in a different terminal:

docker stop kill-sleep

We observe the same 10 second delay / timeout.

A Solution

Now let's handle the SIGTERM. Backgrounding and waiting for sleep are due to how bash handles signals (see this for more).

run.sh

#!/bin/sh

die_func() {
        echo "oh no"
        sleep 2
        exit 1
}
trap die_func TERM

echo "sleeping"
sleep 100000 &
wait

Run the commands again, and we see what we are after!

$ time docker stop kill-sleep
kill-sleep

real    0m2.515s
user    0m0.008s
sys     0m0.044s