daemon.json 不控制容器优雅退出时间，真正由 --stop-timeout 或 docker-compose.yml 中的 stop_grace_period 决定，且需应用响应 sigterm。
daemon.json 文件本身不直接控制容器的优雅退出时间。这个时间是由 docker stop 命令或容器运行时（如 kubernetes）决定的，不是 docker 守护进程全局配置项。
真正影响“优雅退出等待时长”的，是容器启动时指定的 --stop-timeout 参数，或者在 docker-compose.yml 中设置的 stop_grace_period。daemon.json 负责的是守护进程级行为（如镜像源、日志策略、存储路径等），它没有 stop-timeout 或类似字段。
不过，有两点间接关联你需要注意：
✅ 正确配置优雅退出时间的方式
1. 启动容器时显式指定超时
docker run -d --name myapp --stop-timeout=30 myimage:latest
-
--stop-timeout=30表示docker stop会等待 30 秒，再发送SIGKILL。 - 这个值会覆盖默认的 10 秒，也优先于
STOPSIGNAL的行为逻辑。
2. 在 docker-compose.yml 中配置
services:
app:
image: myimage:latest
stop_grace_period: 30s # 等同于 --stop-timeout=30
3. 确保应用能响应 SIGTERM（关键前提）
即使设置了 60 秒超时，如果程序没监听 SIGTERM，它根本不会开始清理，最终仍被 SIGKILL 强杀。
✅ 示例（Go）：
signal.Notify(c, syscall.SIGTERM, syscall.SIGINT) <hr><h3>❌ <a style="color:#f60; text-decoration:underline;" title="daemon" href="https://m.php.cn/zt/372630.html" target="_blank">daemon</a>.<a style="color:#f60; text-decoration:underline;" title="js" href="https://m.php.cn/zt/15802.html" target="_blank">js</a>on 中「不能」也不能「不应」配什么</h3>
- 没有
stop-timeout、graceful-shutdown、termination-timeout等字段； - 不要试图在
daemon.json里加"stop-timeout": 30—— Docker 会忽略该字段，且可能启动失败； -
daemon.json的live-restore: true是另一回事：它让 Docker daemon 自身重启时不杀容器，和容器内应用是否优雅退出无关。
? 验证是否生效的小技巧
停止后立刻检查：
docker ps -a --format "table {{.Names}}\t{{.Status}}" | grep myapp
# 显示 Exited (0) → 正常退出；Exited (137) → 被 SIGKILL 杀掉（超时或未响应）
docker logs myapp | tail -5
# 应看到类似 "received SIGTERM", "shutting down gracefully", "cleanup done"
不复杂但容易忽略：超时值要匹配真实清理耗时，比如数据库刷盘+连接池关闭+服务反注册共需 22 秒，那就设 --stop-timeout=25，留点余量。
