最常见的退出代码，它们的含义以及导致它们的原因
Docker容器退出代码-如何使用它们进行故障排除？
这是我遇到的最常见的问题之一：“为什么我的容器没有运行？”
码头集装箱出口代码可以帮助解决此问题吗？
回答此问题的第一步是识别Docker容器的退出代码。退出代码可以提示停止容器运行的情况。本文列出了使用Docker容器时最常见的退出代码，旨在回答两个重要问题：
- 这个特定的退出代码是什么意思？
- 导致此退出代码的动作是什么？
这最终将有助于回答最初的问题：“为什么我的容器没有运行？”
如何查找退出代码
选项1：列出所有退出的容器
1 | docker ps --filter“状态=退出” |
选项2：按容器名称进行的Grep
1 | docker ps -a grep <容器名称>示例：docker ps -a | grep hello-world |
选项3：按容器ID检查
1 | 码头工人检查<container-id> --format ='{{。State.ExitCode}}'示例：码头工人检查ca6cbb290468 --format ='{{。State.ExitCode}}' |
退出码
与Docker容器关联的常见退出代码为：
- 退出代码0：缺少附加的前台进程
- 退出代码1：指示由于应用程序错误而导致的失败
- 退出代码137：指示由于容器收到SIGKILL而失败（手动干预或“ oom-killer” [OUT-OF-MEMORY]）
- 退出代码139：指示由于收到容器SIGSEGV而失败
- 退出代码143：指示由于收到容器而失败SIGTERM
退出码0
- 退出代码0指示特定的容器没有附加的前台进程。
- 此退出代码是所有其他后续退出代码的例外。这并不一定意味着发生了不好的事情。
- 如果开发人员想要在容器完成其工作后自动停止其容器，则使用此退出代码。
这是一个使用公共docker容器的示例-“ hello-world”。如果在系统或VM实例上安装了docker，请运行以下命令：
1 | docker运行hello-world |
您将收到一条消息，“您好，码头工人！” 但尝试使用以下代码查找容器：
1 | 泊坞窗ps -a | grep hello-world |
您会注意到该容器已退出，并且退出代码为0。这是因为该容器没有附加任何前台进程，例如Java进程或运行直到发生SIGTERM事件的Shell进程。
退出码0
退出代码1
- 指示容器由于应用程序错误或Dockerfile中对容器中不存在的文件的错误引用而停止。
- 应用程序错误可能很简单，例如“除以0”，也可能很复杂，例如“引用与相同名称和类的现有不兼容Bean定义冲突的Bean名称”。
- Dockerfile中对容器中不存在的文件的错误引用可以像错字一样简单（下面的示例使用
sample.ja代替sample.jar）
退出代码1
退出代码137
- 这表明容器收到了SIGKILL
- 引发SIGKILL的常见事件是docker kill。这可以由用户或由docker守护程序手动启动：
1 | 码头工人杀死<container-id> |
docker kill可以由用户或主机手动启动。如果由主机启动，则通常是由于内存不足。要确认容器是否由于内存不足而退出，请docker inspect针对以下部分的容器ID进行验证，并检查其是否OOMKilled为true（这表明容器内存不足）：
1 | “状态”：{ |
退出代码139
- 这表明该容器收到了SIGSEGV
- SIGSEGV指示分段错误。当程序尝试访问不允许访问的存储位置或试图以不允许的方式访问存储位置时，会发生这种情况。
- 从Docker容器的角度来看，这要么表明应用程序代码有问题，要么有时表明容器使用的基本映像有问题。
退出代码143
- 这表明该容器收到了SIGTERM。
- 发起SIGTERM的常见事件是
docker stop或docker-compose stop。在这种情况下，有一个手动终止操作迫使容器退出：
1 | docker stop <container-id> |
- 注意：有时
docker stop还会导致退出代码137。通常，如果绑定到容器的应用程序无法处理SIGTERM，则通常会发生这种情况-docker守护程序等待十秒钟，然后发出SIGKILL
Docker容器的一些不常见的退出代码（通常使用shell脚本）
- 退出代码126：权限问题或命令不可执行
- 退出代码127：shell脚本中可能出现拼写错误且字符无法识别的情况