我太懂你这个糟心的问题了！之前用任务管理工具调度Docker任务时也踩过一模一样的坑——明明把docker run进程杀了，结果容器在后台该跑还是跑，完全不受控。下面给你几个亲测好用的解决办法：

方法一：给docker run加--init参数 #

这是最省心的官方方案。Docker的--init选项会在容器内部启动一个标准的init进程作为PID 1，它能帮你处理信号转发、回收僵尸进程，关键是当docker run收到SIGTERM/SIGHUP这类终止信号时，它能正确把信号传递给容器里的应用，让应用正常退出，容器也会跟着停止。

用法很简单，直接在命令里加参数就行：

docker run -ti --rm --init your-image:tag

方法二：用脚本捕获信号，主动停容器 #

如果没法用--init，可以写个小脚本代替直接执行docker run，让脚本负责监听终止信号，收到信号时主动调用docker stop停容器。

比如这个示例脚本：

#!/bin/bash
# 启动容器并记录容器ID
CONTAINER_ID=$(docker run -d --rm your-image:tag)

# 定义清理函数：收到终止信号时停止容器
cleanup() {
    echo "Stopping container $CONTAINER_ID..."
    docker stop $CONTAINER_ID
    exit 0
}

# 捕获常见的终止信号
trap cleanup SIGTERM SIGHUP SIGINT

# 等待容器自然结束，脚本会一直挂到容器正常退出
docker wait $CONTAINER_ID

这样不管任务管理系统给脚本发什么终止信号，脚本都会主动去停容器，再也不会出现容器“失联”的情况。

方法三：修正容器内PID 1的信号处理逻辑 #

如果你的容器镜像里的PID 1进程不响应信号，那可以修改镜像让它能正确处理SIGTERM：

• 如果是用shell脚本当PID 1，记得开头加#!/bin/bash -e，并且用exec启动最终的应用（比如exec python app.py），这样信号能直接传递给应用；
• 如果是自定义应用，要在代码里注册SIGTERM的处理函数，收到信号后优雅退出。

不过这个方法需要改镜像，麻烦一点，优先推荐前两个方案。

方法四：别上来就用kill -9 #

尽量让任务管理系统先发SIGTERM/SIGHUP这类优雅终止信号，等几秒没反应再用kill -9强制终止。因为kill -9会直接把docker run进程拍死，Docker daemon根本没机会收到通知，自然不会去停容器。如果任务管理系统支持配置终止信号顺序，一定要先试试优雅终止。

备注：内容来源于stack exchange，提问作者interfect