现在给 my-app1 发送 SIGTERM 信号试试，已经无法退出程序了！在这个场景中，应用程序由 bash 脚本启动，bash 作为容器中的 1 号进程收到了 SIGTERM 信号，但是它没有做出任何的响应动作。
我们可以通过：
$ docker container stop my-app1
# or
$ docker container kill --signal="SIGKILL" my-app1
退出应用，它们最终都是向容器中的 1 号进程发送了 SIGKILL 信号。很显然这不是我们期望的，我们希望程序能够收到 SIGTERM 信号优雅的退出。
在脚本中捕获信号创建另外一个启动应用程序的脚本文件 app2.sh，内容如下：
#!/usr/bin/env bash
set -x
pid=0
# SIGUSR1-handler
my_handler() {
echo "my_handler"
}
# SIGTERM-handler
term_handler() {
if [ $pid -ne 0 ]; then
kill -SIGTERM "$pid"
wait "$pid"
fi
exit 143; # 128 + 15 -- SIGTERM
}
# setup handlers
# on callback, kill the last background process, which is `tail -f /dev/null` and execute the specified handler
trap 'kill ${!}; my_handler' SIGUSR1
trap 'kill ${!}; term_handler' SIGTERM
# run application
node app &
pid="$!"
# wait forever
while true
do
tail -f /dev/null & wait ${!}
done
这个脚本文件在启动应用程序的同时可以捕获发送给它的 SIGTERM 和 SIGUSR1 信号，并为它们添加了处理程序。其中 SIGTERM 信号的处理程序就是向我们的 node 应用程序发送 SIGTERM 信号。
然后创建 Dockerfile2 文件，内容如下：
FROM iojs:onbuild
COPY ./app.js ./app.js
COPY ./app2.sh ./app2.sh
COPY ./package.json ./package.json
RUN chmod +x ./app2.sh
EXPOSE 3000
ENTRYPOINT ["./app2.sh"]
接下来创建镜像：
$ docker build --no-cache -t signal-app2 -f Dockerfile2 .
然后启动容器运行应用程序：
$ docker run -it --rm -p 3000:3000 --name="my-app2" signal-app2
此时 node 应用在容器中的进程号也不是 1，但是它却可以接收到 SIGTERM 信号并优雅的退出了：
容器中的 1 号进程是非常重要的，如果它不能正确的处理相关的信号，那么应用程序退出的方式几乎总是被强制杀死而不是优雅的退出。究竟谁是 1 号进程则主要由 EntryPoint, CMD, RUN 等指令的写法决定，所以这些指令的使用是很有讲究的。
Linux公社的RSS地址：https://www.linuxidc.com/rssFeed.aspx