linux - 当 docker 使用 `/bin/sh -c` 运行 SIGTERM 时，SIGTERM 未到达 Node 脚本

Question

当我的 Dockerfile 以

结尾时

CMD node .

docker 使用命令 /bin/sh -c "node ." 运行该容器而不是简单的 node . (我知道，我可以用 CMD ["node", "."] 做到这一点)。

我认为这种行为实际上很好，因为这意味着在容器内 PID1是 /bin/sh而不是我不起眼的 Node 脚本。

如果我理解正确PID1负责收割孤立的僵尸进程，我真的不想对此负责...所以如果 /bin/sh能做到，那就太好了。 (其实我以为这就是 docker 重写我的 CMD 的原因)。

问题是当我发送 SIGTERM通过 /bin/sh -c "node ." 到容器(以 docker-composer stop 开头)或 docker-composer kill -s SIGTERM ，信号没有到达我的node进程，因此每次都会被 SIGKILL 强行杀死10 秒宽限期后。不好看。

有没有办法让别人管理我的僵尸并让我的 Node 实例接收 docker 发送的信号？

Answer 1

我认为你必须了解 ENTRYPOINT 的角色和 CMD ，并使用 ENTRYPOINT (执行形式)方式在您的Dockerfile .

ENTRYPOINT ，它指定容器的启动可执行文件，是 Docker 容器的核心部分。每个容器必须有一个入口点来决定从哪里开始。默认值为/bin/bash -c .此外，CMD 设置的所有内容将附加到 ENTRYPOINT作为论据。

因此，如果您未能指定 ENTRYPOINT在您的Dockerfile ，实际入口点是 /bin/bash -c {your_command_in_CMD} ，不幸的是不传递信号。

ENTRYPOINT有两种形式:执行形式和shell形式

• 执行形式:ENTRYPOINT ["executable", "param1", "param2"]
• shell形式:命令param1 param2

作为 Docker reference指出:推荐exec形式，shell形式的缺点是command被/bin/bash -c执行，这可能不适用于信号:

The shell form prevents any CMD or run command line arguments from being used, but has the disadvantage that your ENTRYPOINT will be started as a subcommand of /bin/sh -c, which does not pass signals. This means that the executable will not be the container’s PID 1 - and will not receive Unix signals - so your executable will not receive a SIGTERM from docker stop <container>.