容器“假活真僵”是因为entrypoint脚本未用exec替换pid 1进程，导致信号无法传递；需检查ps -ef中pid 1是否为应用本身，修复方法是在脚本末尾使用exec ./myapp "$@"。
容器启动后无法响应 docker stop、Ctrl+C 或健康检查超时，常是因为 Entrypoint 脚本没用 exec 替换当前进程，导致主程序运行在子 shell 中——信号收不到，PID 1 不是应用本身，容器“假活真僵”。这不是镜像构建失败，而是启动逻辑缺陷。
确认 PID 1 是否为预期进程
先验证问题是否存在：
- 启动容器后执行
docker exec -it <container> ps -ef</container>，看 PID 1 是不是你的应用（如node server.js），还是/bin/sh或/bin/bash - 若 PID 1 是 shell，且你的应用是它的子进程（PPID=1），就说明没 exec
- 进一步验证：执行
docker kill -SIGTERM <container></container>，再查日志或ps，看应用是否真正退出；不退出即为信号未传递
检查 Entrypoint 脚本中是否遗漏 exec
打开镜像中的 entrypoint.sh（可用 docker run --rm -it --entrypoint sh your-image -c 'cat /entrypoint.sh' 查看）：
- 常见错误写法：
./myapp "$@"或bash start.sh—— 这会 fork 新进程，shell 仍占 PID 1 - 正确写法必须是：
exec ./myapp "$@"或exec "$@"（当脚本最后转发 CMD） - 注意：exec 后不能跟任何后续命令；如果需要前置逻辑（如 chown、wait-for-it），exec 必须是最后一行
修复并验证 exec 行为
修改 Dockerfile 或 entrypoint.sh 后重新构建镜像：
- 确保 exec 出现在脚本末尾，且参数完整（如
"$@"包含所有传入参数） - 构建后测试：
docker run --rm -it your-image sh -c 'echo $$; exec sleep 30'，再docker exec <id> ps -ef</id>确认 PID 1 是 sleep - 生产环境建议加一行诊断：
echo "PID 1: $(ps -o pid,comm= -p 1)" >&2输出到 stderr，便于日志观察
替代方案：用 shell 形式 CMD 避免手动 exec（慎用）
如果不想改脚本，可绕过 entrypoint，直接用 shell 形式启动：
docker run --rm -it --entrypoint '' your-image sh -c 'exec ./myapp "$@"' --arg1 --arg2- 但该方式放弃 entrypoint 的初始化能力，仅适合临时调试
- 长期使用仍推荐修复脚本，保持入口统一和信号健壮性
