本文介绍了 Docker 容器优雅退出的重要性，并详细讲解了 Linux 常见信号及其在容器中的应用。文章重点阐述了 Docker stop 和 kill 命令对信号的支持，并以 Go 程序为例演示了如何接收和处理 SIGTERM 信号，最终实现容器的优雅退出。

😊 **Linux 常见信号与容器退出码**：文章首先概述了 Linux 常见信号，如 SIGTERM 和 SIGKILL，并解释了它们在容器退出时产生的不同影响。同时，文章还介绍了 Docker 容器常见的退出码，例如 Exit Code 137、139 和 143，并分析了它们背后的原因。

😊 **Docker 容器服务对信号的支持**：文章深入探讨了 Docker 对 Linux 信号的支持，包括 docker stop、kill 和 rm 命令，以及 docker daemon 进程对信号的处理方式。文章详细介绍了每个命令对信号的发送机制，以及如何自定义信号发送和超时时间。

😊 **业务服务容器优雅停止案例**：文章以一个简单的 Go 程序为例，演示了如何在程序中接收和处理 TERM 信号，并解释了如何将程序打包到容器中并运行。文章还指出了在 Dockerfile 中使用 CMD 和 ENTRYPOINT 命令时需要注意的问题，并强调了使用 exec 格式的重要性。

😊 **Docker 容器优雅退出的最佳实践**：文章总结了在 Docker 容器中实现优雅退出的最佳实践，建议使用 docker stop 命令来停止容器，并确保应用程序能够接收和处理 SIGTERM 信号。文章还提醒了在 Dockerfile 中设置 ENTRYPOINT 或 CMD 时，应使用 exec 格式，以确保信号正确传递给应用程序。

😊 **Docker 容器退出码分析**：文章深入分析了 Docker 容器的退出码，包括正常的退出状态码（0 到 127）和信号终止导致的退出状态码（128 到 255）。文章解释了信号编号加上 128 作为退出状态码的原因，以及这种设计在容器环境中的重要性。

人艰不拆_zmc 2024-08-08 07:15 广东

在Docker中，为实现容器的优雅退出，确保应用程序能接收和处理SIGTERM信号是至关重要的。

一、概述

不论是什么类型的应用，都会希望在服务停止前能够收到停止通知，有一定的时间做退出前的释放资源、关闭连接、不再接收外部请求等工作。比如你的应用正在处理HTTP请求，你希望在停止前能完成所有未完成的请求；如果你的应用正在写入文件，你也许希望在停止容器前能够正确的刷新数据到磁盘并关闭文件。

二、Linux常见信号

要了解应用优雅停止方法，我们先回顾一下与容器相关的Linux常见信号。

信号是一种进程间通信的形式。一个信号就是内核发送给进程的一个消息，告诉进程发生了某种事件。进程需要为自己感兴趣的信号注册处理程序，举例：

为了能让程序优雅的退出(接到退出的信号后，对资源进行清理)，一般程序都会处理SIGTERM信号。与SIGTERM信号不同，SIGKILL信号会粗暴的结束一个进程；




许多守护进程会通过处理SIGHUP信号实现热加载配置文件。

使用 kill -l 命令会显示Linux支持的信号列表。其中编号为1 ~ 31的信号为传统UNIX支持的信号，是不可靠信号(非实时的)，编号为32 ~ 63的信号是后来扩充的，称做可靠信号(实时信号)。

下面对常用的信号进行说明：

SIGHUP(1)

当用户终端连接结束时，系统会像所有运行中的进程发出这个信号；通常在热加载配置文件时候也会使用该信号。wget命令就注册了SIGHUP(1)信号，这样就算你退出了Linux登录，wget也能继续下载文件。同样的，如Docker/Nginx/LVS等服务也会注册SIGHUP(1)信号，实现服务的热加载配置文件功能。

SIGINT(2)

程序终止(interrupt)信号，在用户键入INTR字符(通常是Ctrl+C)时发出，用于通知前台进程组终止进程。

SIGQUIT(3)

和SIGINT类似，但由QUIT字符(通常是Ctrl+反斜杠)来控制。Nginx就是通过注册这个信号来实现优雅停止服务的。

SIGKILL(9)

立刻结束程序。该信号不能被阻塞、处理和忽略，不能在程序中被获取到。

SIGTERM(15)

程序结束(Terminate)信号，又叫请求退出信号，与SIGKILL不同的是该信号可以被阻塞和处理，我们可以通过在程序中注册该信号来实现服务的优雅停止。使用kill命令缺省会发出这个信号。

SIGCHLD(17)

子进程结束时，一般会向父进程发送这个信号。Nginx是个多进程程序，master进程和worker进程通信就使用的这个信号。

三、Docker容器常见退出码

Exit Code 1

程序错误，或者Dockerfile中引用不存在的文件，如 entrypoint中引用了错误的包

程序错误可以很简单，例如“除以0”，也可以很复杂，比如空引用或者其他程序 crash

Exit Code 137

表明容器收到了SIGKILL信号，进程被杀掉，对应kill -9

引发SIGKILL的是docker kill。这可以由用户或由docker守护程序来发起，手动执行：docker kill

137 比较常见，如果 pod 中的limit 资源设置较小，会运行内存不足导致OOMKilled，此时state 中的”OOMKilled”值为true，你可以在系统的 dmesg 中看到 oom 日志

Exit Code 139

表明容器收到了SIGSEGV信号，无效的内存引用，对应kill -11

一般是代码有问题，或者 docker 的基础镜像有问题

Exit Code 143

表明容器收到了SIGTERM信号，终端关闭，对应kill -15

一般对应docker stop 命令

有时docker stop也会导致Exit Code 137。发生在与代码无法处理SIGTERM的情况下，docker进程等待十秒钟然后发出SIGKILL强制退出。

不常用的一些 Exit Code

Exit Code 126: 权限问题或命令不可执行

Exit Code 127: Shell脚本中可能出现错字且字符无法识别的情况

Exit Code 1 或 255：因为很多程序员写异常退出时习惯用 exit(1) 或 exit(-1)，-1 会根据转换规则转成 255。这个一般是自定义 code，要看具体逻辑

退出状态码的区间

必须在 0-255 之间，0 表示正常退出

外界将程序中断退出，状态码在 129-255

程序自身异常退出，状态码一般在 1-128

假如写代码指定的退出状态码时不在 0-255 之间，例如: exit(-1)，这时会自动做一个转换，最终呈现的状态码还是会在 0-255 之间。我们把状态码记为 code，当指定的退出时状态码为负数，那么转换公式如下：256 – (|code| % 256)

对于被信号终止的进程，操作系统会将信号编号加上128，作为进程的退出状态码。这是因为在Unix系统中，信号编号的范围通常是1到31，而进程退出状态码的范围是0到255，为了区分正常的退出状态码和信号终止导致的退出状态码，就将信号编号加上128。

具体来说：

如果一个进程接收到了信号编号为9（SIGKILL），那么它的退出状态码就是 128 + 9 = 137。

如果一个进程接收到了信号编号为15（SIGTERM），那么它的退出状态码就是 128 + 15 = 143。

这种设计保证了在获取进程退出状态码时，可以区分出是正常退出（0到127范围内）还是信号终止（128到255范围内）。在Docker等容器环境中，这种区分特别重要，因为容器的退出状态码可以帮助用户或管理程序了解容器是如何结束的，从而采取相应的处理措施。

四、Docker容器服务对信号的支持

Docker对Linux Signal也做了很多的支持。

1、docker stop命令信号支持

当我们用docker stop命令来停掉容器的时候，docker默认会允许容器中的应用程序有10秒的时间用以终止运行。我们可以通过在执行docker stop命令时手动指定--time/-t参数来自定义一个stop时间长度。

→ docker stop --helpUsage:  docker stop [OPTIONS] CONTAINER [CONTAINER…]Stop one or more running containersOptions:--help      Print usage  -t, --time int  Seconds to wait for stop before killing it (default 10)

在docker stop命令执行的时候，会先向容器中PID为1的进程(main process)发送系统信号SIGTERM，然后等待容器中的应用程序终止执行，如果等待时间达到设定的超时时间，如默认的10秒，会继续发送SIGKILL的系统信号强行kill掉进程。在容器中的应用程序，可以选择忽略和不处理SIGTERM信号，不过一旦达到超时时间，程序就会被系统强行kill掉。

2、docker kill命令信号支持

默认情况下，docker kill命令不会给容器中的应用程序有任何gracefully shutdown的机会，它会直接发出SIGKILL的系统信号以强行终止容器中程序的运行。

查看docker kill命令的帮助我们看到，除了默认发送SIGKILL信号外，还允许我们发送一些自定义的系统信号：

→ docker kill --helpUsage:  docker kill [OPTIONS] CONTAINER [CONTAINER…]Kill one or more running containersOptions:--help            Print usage  -s, --signal string  Signal to send to the container (default "KILL")

比如，如果我们想向docker中的程序发送SIGINT信号，我们可以这样来实现：

docker kill --signal=SIGINT container_name

与docker stop命令不一样的地方在于，docker kill没有任何的超时时间设置，它会直接发送SIGKILL信号，或者用户指定的其他信号。

3、docker rm命令信号支持

docker rm命令用于删除已经停止运行的容器，我们可以添加--force或-f参数强行删除正在运行的容器。使用这个参数后，docker会先给运行中的容器发送SIGKILL信号，强制停掉容器，然后再做删除。

例如，强制删除正在运行的名称为web容器。

docker rm -fv web

4、docker daemon进程对信号支持（常用功能）

docker daemon进程会接收SIGHUP信号，接收后会重新reload daemon.json配置文件。

我们为dockerd进程发送一个SIGHUP信号：

root@vm10-1-1-28:~# kill -SIGHUP $(pidof dockerd)root@vm10-1-1-28:~# 或者root@vm10-1-1-28:~# systemctl reload docker

查看docker daemon的日志可以看到，docker daemon接收这个信号并重新reload daemon.json配置文件

root@vm10-1-1-28:~# journalctl -u docker.service -f-- Logs begin at Sun 2018-01-07 09:17:01 CST. --Jan 18 16:20:11 vm10-1-1-28.ksc.com dockerd[26668]: time="2018-01-18T16:20:11.262904839+08:00" level=info msg="Got signal to reload configuration, reloading from: /etc/docker/daemon.json"Jan 18 16:21:41 vm10-1-1-28.ksc.com systemd[1]: Reloading Docker Application Container Engine.

所以在你修改完/etc/docker/daemon.json文件后，可以直接给Docker发送一个SIGHUP信号实现配置文件的reload，而不需要重启docker daemon。

注意：systemctl reload docker 命令通常不会导致机器上的容器重启。这个命令的作用是让 Docker 守护进程重新加载其配置文件，而不会中断正在运行的容器。它和 systemctl restart docker 是不同的，后者会停止并重新启动 Docker 服务，从而导致所有容器重启。

五、业务服务容器优雅停止案例

不论什么服务，要想实现优雅停止，都是希望在停止前告诉程序，让程序能有一定的时间处理、保存程序执行现场，优雅的退出程序。下面我们准备了一个通用案例，演示如何在程序中接收并处理TERM信号。

通过了解上面Docker容器服务对信号的支持我们知道，docker kill命令适用于强行终止程序并实现快速停止容器。而如果希望程序能够gracefully shutdown的话，docker stop才是不二之选，这样我们可以让程序在接收到SIGTERM信号后，有一定的时间处理（默认10秒）、保存程序执行现场，优雅的退出程序。

接下来我们写一个简单的Go程序来实现信号的接收与处理。程序在启动过后，会一直阻塞并监听系统信号，直到监测到对应的系统信号后，输出到控制台并退出执行。

// main.gopackage mainimport ("fmt""os""os/signal""syscall")func main() {    fmt.Println("Program started…")    ch := make(chan os.Signal, 1)// notify signal SIGTERM(15)    signal.Notify(ch, syscall.SIGTERM)// notify signal SIGINT(2)    signal.Notify(ch, syscall.SIGINT)    s := <-chswitch {case s == syscall.SIGINT:        fmt.Println("SIGINT received!")//Do something…case s == syscall.SIGTERM:        fmt.Println("SIGTERM received!")//Do something…    }    fmt.Println("Exiting…")}

接下来使用交叉编译的方式来编译程序，让程序可以在Linux下运行：

CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o graceful

编译好之后。我们做测试：

1、测试接收SIGTNT信号，在前台启动进程，然后输入Ctrl + C发送SIGINT(2)信号

zmc@ubuntu ~/r/g/s/edit> ./gracefulProgram started…^CSIGINT received!Exiting…zmc@ubuntu ~/r/g/s/edit>

2、测试接收SIGTERM信号

zmc@ubuntu ~/r/g/s/edit> ./graceful &Program started…zmc@ubuntu ~/r/g/s/edit> ps -ef | grep gracefulzmc  21223  21082  0 15:57 pts/21  00:00:00 ./gracefulzmc  21287  21082  0 15:57 pts/21  00:00:00 grep --color=auto gracefulzmc@ubuntu ~/r/g/s/edit> kill 21223SIGTERM received!Exiting…“./graceful &” has endedzmc@ubuntu ~/r/g/s/edit>

3、将上面程序打包到容器中运行

Dockerfile

FROM alpine:latestADD graceful /gracefulCMD ["/graceful"]

在处理SIGTERM信号常见的一个坑

我们都知道，通过在Dockerfle中使用CMD、ENTRYPOINT命令可以定义容器启动命令，关于这两个命令的区别这里就不讲了，我们只讲在使用时候一定要注意的问题。

这两个命令都支持下面几种格式：

shell 格式：CMD <命令>

exec 格式：CMD ["可执行文件", "参数1", "参数2"...]

参数列表格式：CMD ["参数1", "参数2"...]。在指定了 ENTRYPOINT 指令后，用 CMD 指定具体的参数。

一般推荐使用 exec格式，这类格式在解析时会被解析为 JSON 数组，因此一定要使用双引号 "，而不要使用单引号'。

如果使用 shell 格式的话，实际的命令会被包装为 sh -c 的参数的形式进行执行。比如：

CMD echo $HOME

在实际执行中，会将其变更为：

CMD [ "sh", "-c", "echo $HOME" ]

因此容器的主进程是sh，当给容器发送信号，接收信号的是sh进程，sh进程收到信号后会直接退出，自然就会令容器退出。我们的程序永远收不到信号。

注意：exec 格式这种写法避免了 Docker 自动将 CMD 转换为 sh -c 形式的操作，因为 JSON 数组格式的 CMD 已经明确指定了要执行的命令路径或文件。上面示例，docker在容器启动时会直接执行 /graceful（不包装任何参数）。

镜像打包过程：

zmc@ubuntu ~/r/g/s/edit> docker build -t graceful-golang-case:1.0.0 .Sending build context to Docker daemon 1.953 MBStep 1/4 : FROM alpine:latest---> 3fd9065eaf02Step 2/4 : LABEL maintainer "opl-xws@xiaomi.com"---> Using cache---> 6cc05b3f0ed0Step 3/4 : ADD graceful /graceful---> Using cache---> 4a47b371a124Step 4/4 : CMD /graceful---> Using cache---> f1841c0035afSuccessfully built f1841c0035afzmc@ubuntu ~/r/g/s/edit>

4、启动容器

zmc@ubuntu ~/r/g/s/edit> docker run -d --name graceful graceful-golang-case:1.0.008d871007b58e55e9552cff23960c80faf51bf8637014a745dec060b80ac9a6fzmc@ubuntu ~/r/g/s/edit> docker psCONTAINER ID        IMAGE                                                    COMMAND            CREATED            STATUS              PORTS                    NAMES08d871007b58        graceful-golang-case:1.0.0  "/graceful"        10 seconds ago      Up 9 seconds                                gracefulzmc@ubuntu ~/r/g/s/edit>

5、查看容器输出，能看到程序已经正常启动

zmc@ubuntu ~/r/g/s/edit> docker logs gracefulProgram started…zmc@ubuntu ~/r/g/s/edit>

6、接着我们要使用docker stop看程序能否响应SIGTERM信号

我们都知道docker stop默认在发出SIGTERM信号后的10秒钟，再发送SIGKILL信号强制停掉容器内所有进程，删除容器，假如我的程序处理很复杂，10秒内干不完清理工作，所以我在执行docker stop时自定义让2分钟后再强制kill掉我的容器：

zmc@ubuntu ~/r/g/s/edit> docker stop --time=120 gracefulgracefulzmc@ubuntu ~/r/g/s/edit> docker logs gracefulProgram started…SIGTERM received!Exiting…zmc@ubuntu ~/r/g/s/edit>

查看上面日志，我们可以看到，我们程序确实可以对Docker发来的SIGTERM信号进行处理。

六、总结

在Docker中，为了实现容器的优雅退出，确保你的应用程序能够接收和处理SIGTERM信号是至关重要的。推荐使用docker stop命令来停止容器，因为这会发送SIGTERM信号给容器内的进程，允许它们有机会完成未完成的任务并正常退出。相比之下，直接使用docker rm -f或docker kill可能会强制终止进程，导致数据丢失或不一致的状态。此外，在Dockerfile中设置ENTRYPOINT或CMD时，应使用exec格式，以确保信号正确传递给应用程序。

作者丨人艰不拆_zmc

来源丨网址：https://www.cnblogs.com/zhangmingcheng/p/18252004

dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn

跳转微信打开