关于AWS KCL在Docker环境中捕获TERM关闭信号的问题

当你在终端直接运行KCL时，Java进程能正常接收TERM信号并输出关闭日志，但在Docker容器里经常遇到信号无法传递的问题，核心原因是容器内PID 1进程的信号处理机制，下面是两种可靠的解决方法：

方法1：让Java进程成为容器的PID 1进程 #

Docker默认会将PID 1分配给容器启动的第一个进程。如果你的启动命令是通过脚本或者间接调用Java，脚本进程会占用PID 1，而shell脚本默认不会将TERM信号转发给子进程（也就是KCL的Java进程），导致信号丢失。

解决方式是用exec命令替换启动进程，让Java直接成为PID 1：

• 如果直接在docker run中指定命令，调整为：

  docker run -v /tmp:/tmp -v ~/.aws:/root/.aws -d cde3946e2cf9 exec ./bin/kcl-bootstrap -p app.properties -j /usr/bin/java -e
  

• 如果是通过Dockerfile的ENTRYPOINT或CMD定义启动命令，修改为exec形式：

  ENTRYPOINT ["exec", "./bin/kcl-bootstrap", "-p", "app.properties", "-j", "/usr/bin/java", "-e"]
  

这样Java进程会直接占据PID 1，当你执行docker stop或者向容器发送TERM信号时，信号会直接传递给KCL进程，触发正常的关闭流程。

方法2：使用Docker的--init参数启用信号转发 #

Docker支持通过--init参数引入tini作为容器的init进程（PID 1），tini会自动将接收到的信号转发给容器内的所有子进程，即使Java不是PID 1也能捕获到TERM信号。

使用方式很简单，在docker run命令中加上--init：

docker run --init -v /tmp:/tmp -v ~/.aws:/root/.aws -d cde3946e2cf9 ./bin/kcl-bootstrap -p app.properties -j /usr/bin/java -e

这种方式不需要修改启动脚本或Dockerfile，适合快速调试或现有镜像无法修改的场景。

验证方法 #

启动容器后，执行docker ps获取容器ID，然后发送TERM信号：

docker kill -s TERM <container-id>

接着查看容器日志：

docker logs <container-id>

如果能看到类似终端中输出的Shutdown requested和Shutting down...日志，说明信号已成功传递。

内容的提问来源于stack exchange，提问作者Tin Ng