信号的理念以及Dockerfile中ENTRYPOINT和CMD指令

1 信号

信号是事件发生时对进程的通知机制，有时也称之为软件中断。

# kill -l 1) SIGHUP       2) SIGINT       3) SIGQUIT       4) SIGILL       5) SIGTRAP      6) SIGABRT       7) SIGBUS       8) SIGFPE       9) SIGKILL 10) SIGUSR1    11) SIGSEGV     12) SIGUSR2 13) SIGPIPE    14) SIGALRM     15) SIGTERM... ...

• 1) SIGHUP当终端断开（挂机）时，将发送该信号给终端控制进程。SIGHUP 信号还可用于守护进程（比如，init 等）。许多守护进程会在收到 SIGHUP 信号时重新进行初始化并重读配置文件。

• 2) SIGINT当用户键入终端中断字符（通常为Control-C） 时，终端驱动程序将发送该信号给前台进程组。该信号的默认行为是终止进程。

• 3) SIGQUIT当用户在键盘上键入退出字符（通常为Control-）时，该信号将发往前台进程组。默认情况下，该信号终止进程，并生成用于调试的核心转储文件。进程如果陷入无限循环，或者不再响应时，使用 SIGQUIT 信号就很合适。

• 9) SIGKILL此信号为 “必杀（sure kill）” 信号，处理器程序无法将其阻塞、忽略或者捕获，故而 “一击必杀”，总能终止程序。

• 15) SIGTERM这是用来终止进程的标准信号，也是kill、killall、pkill命令所发送的默认信号。精心设计的应用程序应当为 SIGTERM 信号设置处理器程序，以便其能够预先清除临时文件和释放其它资源，从而全身而退。因此，总是应该先尝试使用SIGTERM信号来终止进程，而把SIGKILL作为最后手段，去对付那些不响应SIGTERM信号的失控进程。

• 20) SIGTSTP这是作业控制的停止信号，当用户在键盘上输入挂起字符（通常为 Control-Z ）时，将该信号给前台进程组，使其停止运行。

值得注意的是，Control-D不会发起信号，它表示 EOF（End-Of-File），关闭标准输入（stdin）管道（比如可以通过Control-D退出当前 shell）。如果程序不读取当前输入的话，是不受 Control-D 影响的。

以上知识大部分都来自 《Linux/UNIX 系统编程手册》，想要了解更多的，可以查看该书上册的 20、21、22 章节。

2 ENTRYPOINT 、 CMD

CMD有三种格式：

• CMD ["executable","param1","param2"]（exec 格式, 推荐使用这种格式）

• CMD ["param1","param2"]（作为 ENTRYPOINT 指令参数）

• CMD command param1 param2（shell 格式，默认 /bin/sh -c ）

ENTRYPOINT有两种格式：

• ENTRYPOINT ["executable", "param1", "param2"]（exec 格式，推荐优先使用这种格式）

• ENTRYPOINT command param1 param2（shell 格式）

其中，不管你Dockerfile用其中哪个指令，两个指令都推荐使用 exec 格式，而不是 shell 格式。原因就是因为使用 shell 格式之后，程序会以/bin/sh -c的子命令启动，并且 shell 格式下不会传递任何信号给程序。这也就导致，在docker stop容器的时候，以这种格式运行的程序捕捉不到发送的信号，也就谈不上优雅的关闭了。

➜  ~ docker stop --help
Usage:  docker stop [OPTIONS] CONTAINER [CONTAINER...]
Stop one or more running containers
Options:      --help       Print usage  -t, --time int   Seconds to wait for stop before killing it (default 10)

➜  ~ docker kill --help
Usage:  docker kill [OPTIONS] CONTAINER [CONTAINER...]
Kill one or more running containers
Options:      --help            Print usage  -s, --signal string   Signal to send to the container (default "KILL")

通过 docker kill的-s选项还可以指定给容器发送的信号。

3 实例

通过 Go 写一个简单的信号处理器：

➜  ~ cat signals.gopackage main
import (    "fmt"    "os"    "os/signal"    "syscall")
func main() {    sigs := make(chan os.Signal, 1)    done := make(chan bool, 1)
    signal.Notify(sigs, syscall.SIGINT, syscall.SIGTERM)
    go func() {        sig := <-sigs        fmt.Println()        fmt.Println(sig)        done <- true    }()
    fmt.Println("awaiting signal")    <-done    fmt.Println("exiting")}

3.1 实例 1

➜  ~ GOOS=linux GOARCH=amd64 go build signals.go➜  ~ lsDockerfile signals    signals.go➜  ~ cat DockerfileFROM busybox
COPY signals /signals
CMD ["/signals"]    # exec 格式执行➜  ~ docker build -t signals .

通过 tmux 开启两个面板，一个运行容器，一个执行 docker stop ：

➜  ~ docker run -it --rm --name signals signalsawaiting signal
terminatedexiting

➜  ~ time docker stop signalssignalsdocker stop signals  0.01s user 0.02s system 4% cpu 0.732 total➜  ~

可以发现，容器停止之前，程序接收到信号并输出相应信息，并且停止总耗时为 0.732 s，达到了优雅的效果。

修改 Dockerfile 中 CMD 执行格式，执行相同操作：

➜  ~ cat DockerfileFROM busybox
COPY signals /signals
CMD /signals        # shell 格式执行➜  ~ docker build -t signals .

➜  ~ docker run -it --rm --name signals signalsawaiting signal➜  ~

➜  ~ time docker stop signalssignalsdocker stop signals  0.01s user 0.01s system 0% cpu 10.719 total

通过 shell 格式之后，可以发现容器停止之前，程序并未接收到任何信号，并且停止时间为 10.719s，说明该容器是被强制停止的。

结论很明显，为了优雅的退出容器，我们应该采用 exec 这种格式。

3.2 实例 2

➜  ~ lsDockerfile signals    signals.go start.sh➜  ~ cat DockerfileFROM busybox
COPY signals /signalsCOPY start.sh /start.sh     # 引入 shell 脚本启动
CMD ["/start.sh"]➜  ~ cat start.sh#!/bin/sh
/signals➜  ~

测试依然引用实例 1 中的方法：

➜  ~ docker run -it --rm --name signals signalsawaiting signal➜  ~

➜  ~ time docker stop signalssignalsdocker stop signals  0.01s user 0.02s system 0% cpu 10.765 total➜  ~

➜  ~ cat start.sh#!/bin/sh
exec /signals   # 加入 exec 执行➜  ~ docker build -t signals .

➜  ~ docker run -it --rm --name signals signalsawaiting signal
terminatedexiting

➜  ~ time docker stop signalssignalsdocker stop signals  0.02s user 0.02s system 4% cpu 0.744 total➜  ~

可以看到，加入 exec 命令之后，程序又可以接收到信号正常退出了。当然，如果你 Dockerfile 中的 CMD 是以 shell 格式运行的，即使启动脚本中加入 exec 也是无效的。再者，如果你的程序本身不能针对信号做一些处理，也就谈不上优雅关闭了。