Docker 容器退出状态码existed

今天在起容器的时候，发现容器出于existed状态，状态码为130，查找后发现，自己启动的时候使用了非后台启动。当手动 ctrl+C 退出命令行的时候，容器也就退出了。开始的时候，不知道状态码含义，纠结了很久，于是把一些状态码的含义搜罗了一下。

• 首先状态码必须在 0-255 之间
• 0 表示正常退出
• 外界中断将程序退出的时候状态码区间在 129-255，(操作系统给程序发送中断信号，比如 kill -9 是 SIGKILL，ctrl+c 是 SIGINT)
• 一般程序自身原因导致的异常退出状态区间在 1-128 (这只是一般约定，程序如果一定要用129-255的状态码也是可以的)

下图为部分状态码：

常见的容器退出状态码解释

Exit Code 0

退出代码0表示特定容器没有附加前台进程

该退出代码是所有其他后续退出代码的例外

这不一定意味着发生了不好的事情。如果开发人员想要在容器完成其工作后自动停止其容器，则使用此退出代码。比如：kubernetes job 在执行完任务后正常退出码为 0

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 -T 中看到 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，要看具体逻辑。

参考文章

Kubernetes故障排查指南-分析容器退出状态码