Docker中exec形式ENTRYPOINT与shell形式CMD的行为及信号传播问题

核心结论 #

你的配置不会产生额外子shell，也不存在信号传播问题，具体原因拆解如下：

关键概念区分 #

Docker中ENTRYPOINT/CMD分两种定义形式，直接决定进程启动逻辑：

• exec形式（数组格式）：Docker直接启动目标进程，该进程会成为容器的PID=1进程，能直接接收操作系统发送的信号（比如SIGTERM停止信号）。
• shell形式（字符串格式）：Docker会自动用/bin/sh -c "你的命令"包装启动，此时sh进程是PID=1，你的目标进程是它的子进程；由于sh默认不会转发信号给子进程，会导致目标进程收不到停止信号，出现优雅关闭失败的问题。

你的配置具体分析 #

你的Dockerfile配置：

ENV JAVA_OPTS '-XX:+UseG1GC -Xms512m -Xmx1536m'
ENTRYPOINT ["java"]
CMD $JAVA_OPTS -jar app.jar

• ENTRYPOINT用了exec形式["java"]，这意味着Docker会直接把java进程作为容器的PID=1进程启动。
• CMD是shell形式的字符串，但此时的处理逻辑和ENTRYPOINT是shell形式时完全不同：当ENTRYPOINT是exec数组时，CMD的字符串会先被Docker做环境变量替换，再被拆分成参数数组，直接作为java进程的启动参数传入。
• 最终容器启动的实际命令等价于：

  java -XX:+UseG1GC -Xms512m -Xmx1536m -jar app.jar
  

  整个过程没有额外的sh子进程，java进程是PID=1，能正常接收所有信号，不存在信号被拦截的问题。

容易踩坑的反例 #

如果把ENTRYPOINT改成shell形式：

ENTRYPOINT java
CMD $JAVA_OPTS -jar app.jar

此时Docker会用/bin/sh -c "java $JAVA_OPTS -jar app.jar"启动，sh是PID=1，java是子进程，这时候发送停止信号给容器，sh不会转发给java，就会出现信号传播问题。

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