为何Docker CLI命令接收SIGTERM信号后以状态码1退出？

核心原因是你终止的是宿主机上的docker run CLI进程，而非容器内部的sleep进程，两者的退出逻辑完全不同：

• 当你执行kill -SIGTERM 75658时，终止的是宿主机的docker run客户端进程。这个进程收到SIGTERM后，会触发自身的信号处理逻辑：它会尝试通知Docker Daemon停止目标容器，但自身会以退出码1结束——因为Docker CLI将用户主动中断（比如外部SIGTERM或Ctrl+C）视为“操作异常终止”，而非被动被信号杀死，所以返回通用错误码1。
• 而当你发送SIGKILL时，docker run进程没有任何机会执行自定义处理逻辑，直接被内核强制终止，此时shell会返回标准的信号终止退出码：128 + 9（SIGKILL编号）=137，这符合预期。

如果想要得到代表SIGTERM的143退出码，你需要终止容器内部的进程而非Docker CLI：

• 方法1：用docker exec进入容器，找到sleep进程并发送SIGTERM
• 方法2：直接使用docker stop命令，它会给容器内PID 1进程发送SIGTERM，容器退出后，docker run的退出码会和容器退出码一致（即143）

验证示例 #

如果执行docker stop命令，再查看退出码：

# shell 1中启动后台容器并记下容器ID
docker run -d --rm alpine:latest sleep 1000
# 假设容器ID是abc123
docker stop abc123
echo $?  # 输出143，符合预期

内容的提问来源于stack exchange，提问作者Zarif Mahfuz