1. 容器退出的那些事儿从137到143的深度解读如果你在运维Docker容器或者在本地开发时用docker run启动一个服务大概率都见过容器运行后突然停止留下一串数字的情况。比如执行docker ps -a查看所有容器时在STATUS那一列除了熟悉的Up更常见的是Exited (137) 2 minutes ago。这个括号里的数字就是容器的退出码。它就像是容器临终前的“遗言”告诉你它为什么“死”了以及“死”得是否安详。对于开发者尤其是运维同学来说读懂这些退出码是快速定位线上服务异常、调试开发环境问题的基本功。今天我们就来把这些常见的退出码掰开揉碎了讲清楚让你下次再遇到时能胸有成竹地说“哦是这个问题我知道怎么搞。”2. 退出码的本质信号与状态码的映射要理解Docker容器的退出码我们得先回到它的根源——Linux进程。Docker容器本质上是一个或多个运行在隔离环境中的Linux进程。当一个进程结束时它会向父进程返回一个退出状态。这个状态是一个8位的整数范围是0到255。这个退出状态主要有两个来源进程主动退出进程执行完毕通过exit()系统调用并传递一个退出码。按照惯例退出码0代表成功Success非0代表某种错误Failure。这也是为什么我们写Shell脚本时常用$?来检查上一条命令是否成功$? -eq 0。进程被动终止进程被操作系统或其他进程发送的信号Signal杀死。在Linux中信号是进程间通信的一种基本方式用来通知进程发生了某个事件。当进程因为信号而终止时它的退出状态是128 信号编号。Docker容器退出码就是其内部主进程PID 1的退出状态。所以我们看到的137、143这些数字都可以通过这个规则来解码。注意这里说的“主进程”通常是由Dockerfile中CMD或ENTRYPOINT指令指定的进程。这个进程的生死直接决定了容器的生死。2.1 如何查看和分析退出码实际操作中我们通过几个简单的命令就能获取和分析退出码。1. 查看已停止容器的退出码最直接的就是docker ps -a在STATUS列会显示Exited (code) ...。docker ps -a --filter statusexited这个命令可以过滤出所有已退出的容器方便集中查看。2. 查看容器详细状态信息docker inspect命令能提供容器的元数据宝库其中就包含退出状态。docker inspect --format{{.State.ExitCode}} container_name_or_id这个命令会直接输出指定容器的退出码数字非常适合用于脚本自动化判断。3. 容器日志是第一现场退出码告诉你“结果”但日志才能告诉你“过程”。在排查时一定要结合容器日志。docker logs container_name_or_id查看日志的末尾部分通常能发现导致进程崩溃的错误信息比如内存不足的OutOfMemoryError、未捕获的异常堆栈等。3. 高频退出码详解与实战应对下面我们针对最常见的几个退出码进行深度拆解并给出具体的排查思路和解决方案。3.1 退出码 137 (128 9 SIGKILL)最“暴力”的终结信号含义SIGKILL(信号9)。这个信号无法被进程捕获、阻塞或忽略是操作系统提供的“立即无条件杀死”指令。进程收到此信号后会立刻终止没有机会进行任何清理工作如关闭文件、释放锁、保存状态等。常见触发场景最典型的原因内存不足 (OOM Killer)。这是生产环境137码的“头号嫌犯”。当宿主机内存紧张时Linux内核的OOM KillerOut-Of-Memory Killer机制会被触发。它会根据一套复杂的评分算法oom_score选择“最坏”的进程杀死以释放内存。被选中的进程就会收到SIGKILL信号。容器化环境下由于cgroup的限制容器内进程的oom_score更容易被调高因此更易被选中。手动强制杀死执行了docker kill container或docker rm -f container命令。宿主机资源紧张不仅是内存在极端CPU、IO压力下系统也可能变得不稳定。容器运行时或宿主机内核问题较为罕见可能是Docker引擎、containerd运行时或内核本身的bug。排查与解决步骤第一步确认是否为OOM查看容器和宿主机日志。最关键的日志在宿主机上# 查看内核日志寻找OOM痕迹 sudo dmesg -T | grep -i killed process # 或直接查看系统日志 sudo journalctl -k --since10 minutes ago | grep -i oom如果看到类似“Out of memory: Killed process [pid] (java/docker)”的日志即可确诊。第二步分析容器内存配置检查容器的内存限制docker inspect --format{{.HostConfig.Memory}} {{.HostConfig.MemorySwap}} container_id如果输出是0 0代表没有限制容器可能无限占用内存直到触发系统OOM。如果有具体数字如104857600代表100MB则说明设置了限制。第三步解决方案合理设置内存限制与请求在docker run时使用-m或--memory参数或在Kubernetes中配置limits.memory和requests.memory。原则是requests应略高于应用平稳运行所需limits可设置得更高以应对峰值但需留足宿主机缓冲空间。docker run -m 512m --memory-reservation 256m my-app:latest优化应用内存使用这是治本之策。对于JVM应用重点调整-Xmx堆最大内存、-Xms堆初始内存以及-XX:MaxMetaspaceSize等参数确保Xmx小于容器内存限制并留出足够空间给堆外内存如线程栈、直接内存、Native库。对于其他应用需使用 profiling 工具如jprofiler,async-profilerfor Java,pproffor Go分析内存泄漏或不当使用。监控与告警建立容器内存使用率的监控如使用PrometheusGrafana采集container_memory_working_set_bytes等指标在内存使用率持续超过80%或快速增长时触发告警以便提前干预。升级硬件或调整部署如果业务量确实增长需要考虑为宿主机增加物理内存或者将内存消耗型服务调度到资源更充足的节点上。实操心得对于Java应用容器内的OOM问题尤其棘手。除了堆内存更要关注MaxDirectMemorySizeNIO直接内存和Metaspace元空间。一个常见的坑是容器内存限制设为1GB-Xmx设为800MB但忽略了默认的MaxDirectMemorySize通常与-Xmx一致导致堆外内存超额。建议明确设置-XX:MaxDirectMemorySize并确保Xmx MaxDirectMemorySize 其他开销约200-300MB 容器内存限制。3.2 退出码 143 (128 15 SIGTERM)优雅的终止信号含义SIGTERM(信号15)。这是一个“优雅终止”信号。进程可以捕获这个信号并执行自定义的清理逻辑如关闭数据库连接、写完缓存、停止接收新请求等然后再自行退出。这是docker stop命令默认发送的信号。常见触发场景执行了docker stop container命令。在Kubernetes中Pod被删除或滚动更新时kubelet会向容器发送SIGTERM。容器编排工具如Docker Compose在停止服务时。宿主机重启或关机前init系统会向所有进程广播SIGTERM。预期行为与问题排查 143本身是一个“正常”的退出码代表容器是被有计划地停止的。通常不需要排查。但是如果容器在收到SIGTERM后没有在默认的30秒内退出Docker会强制发送SIGKILL退出码137。这时问题就变成了“为什么我的应用无法优雅关闭”排查“优雅关闭”失败检查应用是否处理SIGTERM对于Node.js、Python、JavaSpring Boot等现代框架通常内置了信号处理。你需要确认你的应用代码没有覆盖或忽略这些处理逻辑。例如在Node.js中是否监听了process.on(SIGTERM, ...)。调整停止超时时间如果应用关闭确实需要更长时间例如等待长事务完成、大数据量缓存持久化可以在docker run时使用--stop-timeout参数增加等待时间。docker run --stop-timeout 60 my-app:latest # 等待60秒查看关闭期间的日志在docker stop之后立即使用docker logs查看容器最后输出的日志看是否有清理步骤的日志或者是否有错误阻塞了关闭流程。使用docker exec进入容器调试对于复杂应用可以尝试在容器运行时手动发送SIGTERM信号给进程观察其行为。# 找到容器内主进程PID在宿主机上 docker top container_id # 向该PID发送SIGTERM kill -15 pid_from_docker_top3.3 退出码 1通用的应用错误含义退出码1代表进程以“一般性错误”退出。这通常是应用自身的逻辑错误而非被外部信号杀死。常见触发场景应用启动失败这是最常见的情况。例如配置文件错误、路径不存在。依赖的服务如数据库、Redis连接不上。环境变量缺失或格式错误。端口已被占用。应用代码在初始化时抛出未捕获的异常。健康检查失败如果定义了HEALTHCHECK且连续失败Docker可能会将容器标记为unhealthy但不会直接杀死它。退出码1通常不是健康检查直接导致的而是健康检查失败后你手动停止了容器或者编排工具根据策略进行了重启。权限问题容器内进程以非root用户运行时试图写入只读目录或访问特权端口1024失败。依赖库缺失动态链接库.so文件或解释器如Python、Node找不到。排查步骤系统性诊断第一步仔细阅读启动日志这是最直接有效的方法。99%的退出码1问题都能从日志中找到答案。docker logs container_id 21 | head -100 # 查看前100行日志重点关注日志开头的错误堆栈Stack Trace、ERROR/FATAL级别的日志、以及“Cannot”、“Failed to”、“Error”等关键词。第二步检查容器启动命令和配置核对启动命令docker inspect可以查看容器实际的启动命令Args和镜像的入口点Entrypoint。docker inspect --format{{json .Config.Cmd}} container_id docker inspect --format{{json .Config.Entrypoint}} container_id确认命令和参数是否正确特别是文件路径、IP地址等是否因容器环境而变化。检查环境变量docker inspect --format{{json .Config.Env}} container_id | python -m json.tool # 格式化输出确认所有必需的环境变量都已正确设置。第三步模拟启动过程进行调试如果日志信息不足可以尝试以交互模式启动容器并进入Shell手动执行启动命令。# 使用与生产相同的命令和配置但以交互模式启动 docker run -it --rm --env-file prod.env -v $(pwd)/config:/config my-app:latest /bin/bash # 进入容器后手动执行应用的启动命令 ./app-start.sh这样可以观察到最原始的错误输出甚至可以在容器内进行一些基本的调试如检查文件、测试网络连通性ping、curl。第四步检查文件权限和挂载卷如果应用需要写文件确保挂载的卷或容器内目录有正确的写权限。特别是当宿主机目录挂载到容器内时UID/GID的映射可能导致权限问题。可以在docker run时使用-u参数指定用户或者在Dockerfile中用USER指令。# 在容器内查看当前用户和文件权限 docker run -it --rm my-app:latest sh -c whoami id ls -la /path/to/write3.4 退出码 125Docker守护进程自身的错误含义退出码125表示docker run命令本身执行失败甚至没有成功创建和启动容器进程。这是Docker客户端或守护进程报出的错误。常见触发场景镜像不存在docker run指定的镜像名或标签在本地或远程仓库中找不到。docker run non-existent-image:latest # 错误信息Unable to find image non-existent-image:latest locally...无效的Docker命令参数使用了不存在的参数或者参数值格式错误、冲突。docker run --cpu-sharesinvalid_value my-app容器运行时错误更底层的问题例如docker daemon守护进程没有运行。容器运行时如runc执行出错。宿主机内核不支持某些容器特性如用户命名空间。资源限制冲突例如试图设置的内存交换memory-swap值小于内存memory值。docker run -m 100m --memory-swap 50m my-app # 错误swap必须大于等于memory # 错误信息Minimum memoryswap limit should be larger than memory limit排查步骤仔细阅读命令行错误输出Docker客户端会直接打印出详细的错误信息这是诊断125码最主要的信息来源。检查Docker服务状态systemctl status docker # 对于systemd系统 sudo dockerd --debug # 可以尝试以调试模式启动守护进程查看详细日志生产环境慎用验证镜像和命令使用docker images确认镜像存在。使用docker run --help检查命令参数的正确用法。简化命令测试先尝试最简单的docker run -it --rm alpine:latest sh如果能成功再逐步添加你的自定义参数如-v,-p,-e,-m定位是哪个参数导致的问题。3.5 退出码 126 和 127命令或文件找不到这两个退出码都指向“找不到”的问题但层次不同。退出码 126命令调用错误。通常是容器入口点ENTRYPOINT或命令CMD指定的文件存在但无法执行。原因可能是文件不是可执行格式。文件权限不足没有x执行权限。动态链接器如/lib64/ld-linux-x86-64.so.2缺失或损坏对于编译型二进制文件。退出码 127命令未找到。这是更常见的情况表示在$PATH环境变量列出的目录中找不到ENTRYPOINT或CMD指定的命令。例如Dockerfile里写了CMD [python3, app.py]但镜像里根本没有安装python3。排查步骤检查Dockerfile确认ENTRYPOINT或CMD指定的文件或命令在镜像构建后确实存在且路径正确。对于Shell格式的CMD如CMD python app.py要确保Shell本身存在通常是/bin/sh。进入镜像内部检查# 以交互模式启动镜像但不执行默认命令 docker run -it --rm --entrypoint my-image:latest sh # 在容器内检查 which python3 # 检查命令是否存在 ls -la /path/to/entrypoint.sh # 检查文件是否存在及权限 file /path/to/binary # 检查文件类型 ldd /path/to/binary # 检查动态依赖针对126错误对于126错误确保文件有执行权限。在Dockerfile中对于需要执行的脚本记得用COPY后加上RUN chmod x。COPY entrypoint.sh /usr/local/bin/ RUN chmod x /usr/local/bin/entrypoint.sh ENTRYPOINT [/usr/local/bin/entrypoint.sh]对于127错误确保命令已安装并且其所在目录在$PATH中或者使用绝对路径。3.6 其他值得注意的退出码退出码 139 (128 11 SIGSEGV)段错误。这通常是严重的程序Bug如访问了非法内存地址空指针解引用、缓冲区溢出等。遇到此错误需要开发者使用调试工具如gdb分析应用的核心转储文件core dump。在容器中生成和分析core dump比较复杂通常需要在运行容器时挂载/proc/sys/kernel/core_pattern并设置足够的权限。退出码 255这个状态码比较特殊它可能表示容器运行时如runc内部错误或者进程以-1退出exit(-1)但-1会被模256处理成255。当看到255时应首先查看Docker守护进程日志和容器日志寻找更具体的错误信息。4. 系统化排查工具箱与最佳实践掌握了单个退出码的分析方法后我们需要建立一套系统化的排查流程和预防措施。4.1 构建排查决策树当收到容器异常退出的告警时可以遵循以下流程图快速定位方向 此处以文字描述决策树获取退出码通过docker ps -a或docker inspect获取退出码X。判断信号类如果X 128则是由信号引起。计算信号编号S X - 128。S 9 (SIGKILL)- 重点排查内存不足(OOM)、手动kill -9、系统资源问题。查dmesg和宿主机监控。S 15 (SIGTERM)- 属于计划内停止。检查是否是正常的docker stop、滚动更新或缩容。如果停止超时则排查应用优雅关闭逻辑。S 11 (SIGSEGV)-应用程序Bug段错误。需要开发介入调试core dump。判断应用错误类如果X 128。X 0- 正常退出无需处理。X 1-通用应用错误。首要查看容器日志定位启动失败、配置错误、依赖缺失等问题。X 125-Docker命令/守护进程错误。查看docker run命令的即时错误输出检查镜像、参数、Docker服务状态。X 126/127-命令/文件问题。进入镜像检查ENTRYPOINT/CMD指定的文件是否存在、是否有执行权限、依赖是否完整。其他非零值 - 通常是应用自定义的错误码。需要查阅该应用的文档了解不同错误码的含义。4.2 预防胜于治疗最佳实践指南为应用设置合理的资源限制永远不要让你的容器在无限制状态下运行。使用-m、--cpus等参数或通过Kubernetes的limits进行限制。这不仅能防止单个容器耗尽宿主机资源也是保证调度公平性和稳定性的基础。实现应用的健康与就绪检查在Dockerfile中使用HEALTHCHECK指令或在Kubernetes中配置livenessProbe和readinessProbe。这能让编排系统更智能地判断容器状态在应用无响应时自动重启而不是等到彻底崩溃。完善日志记录确保应用将日志输出到标准输出stdout和标准错误stderr这是Docker和Kubernetes生态的“约定”。避免将日志只写到容器内的文件否则docker logs将无法捕获。对于复杂应用考虑集成结构化日志JSON格式和日志收集系统如ELK、Loki。处理SIGTERM实现优雅关闭这是云原生应用的基本素养。确保你的应用在收到SIGTERM后能够完成正在处理的请求、关闭网络监听、释放连接池、保存状态然后再退出。这可以避免滚动更新或缩容时造成请求中断和数据不一致。使用非root用户运行容器在Dockerfile中使用USER指令指定一个非root的普通用户。这遵循了最小权限原则能有效减少安全风险。监控与告警对容器的退出码进行监控。可以配置告警规则当非0退出码特别是137频繁出现时及时通知。同时监控容器的内存使用率、CPU使用率等资源指标。4.3 高级调试技巧当常规手段无法解决问题时可能需要一些更深入的调试方法使用docker exec进入故障容器如果容器尚未退出可以快速进入内部进行检查。docker exec -it container_id /bin/sh调试停止的容器对于已退出的容器虽然不能exec但可以commit成一个新镜像来检查其最终状态。docker commit stopped_container_id debug-image docker run -it --rm --entrypoint/bin/sh debug-image检查容器进程树在宿主机上容器的进程在父进程通常是containerd-shim下。可以使用pstree或ps auxf来查看进程关系有时能发现僵尸进程或异常的父子关系。分析内核调用对于极其棘手的问题如偶发的139错误可能需要使用strace来跟踪进程的系统调用。这需要在容器内安装strace或者在宿主机上附加到容器进程。# 在宿主机上找到容器进程PID docker top container_id # 使用strace跟踪 sudo strace -p container_pid -f -tt -o strace.log理解Docker退出码是掌握容器生命周期管理的关键一环。它不再是控制台上一串冰冷的数字而是容器与你沟通的语言。下次再遇到容器异常退出不妨静下心来按照本文提供的思路从退出码入手结合日志和监控一步步揭开问题的真相。记住稳定的容器化服务始于对每一个细节的洞察。