1. 项目概述为什么Docker退出码值得你花时间研究如果你用过Docker大概率遇到过容器运行着运行着就自己停了的情况。这时候你第一反应可能是docker ps -a看一眼然后发现容器状态是Exited (137)或者Exited (1)。这个括号里的数字就是Docker容器的退出码。它就像容器临终前留下的“遗言”告诉你它到底是怎么“死”的。但很多人看到这个数字第一反应是去搜索引擎里搜“Docker 137错误”而不是去理解这个数字背后的含义。我刚开始用Docker时也这样每次容器异常退出都像在解谜到处找零散的解决方案。直到后来系统地梳理了一遍才发现这些退出码背后有一套清晰的逻辑掌握了它排查问题的效率能提升好几个数量级。这不仅仅是Docker的知识更是Linux进程信号和系统调用返回值的核心体现。今天我就把自己踩过的坑和总结的经验掰开揉碎了讲给你听让你下次再看到退出码时能胸有成竹快速定位根因。2. 退出码的本质容器只是进程的包装要理解Docker退出码首先得抛开“容器”这个抽象概念回到最根本的计算机原理上。一个正在运行的Docker容器本质上就是一个或多个在隔离环境Namespace、Cgroups中运行的Linux进程。容器的“主进程”通常就是你在Dockerfile里用CMD或ENTRYPOINT指定的那个命令。当这个主进程结束时整个容器的使命也就完成了容器随之停止。而进程结束时会向操作系统返回一个整数值这个值就是退出状态码。在Linux/Unix世界里这几乎是一个铁律进程结束必须有一个退出码。Docker做的只是把这个底层操作系统的退出码捕获出来原封不动地展示给你看。所以docker run命令的返回值以及docker ps -a里显示的Exited (xxx)就是这个主进程的退出码。理解这一点至关重要它意味着所有Linux进程的退出码规则都适用于Docker容器。比如0代表成功非0代表失败。排查Docker容器退出问题很大程度上就是在排查这个主进程为什么以及如何退出的。很多退出码直接对应着Linux内核发送给进程的信号。进程被信号杀死时退出码通常是128 信号编号。3. 常见退出码深度解析与实战应对下面我们来逐一拆解那些让你头疼的常见退出码。我会结合具体场景、命令和排查思路让你不仅知道“是什么”更明白“为什么”和“怎么办”。3.1 退出码 0正常退出含义这是最理想的退出状态表示容器内的主进程按照预期正常结束任务已完成。典型场景运行一个一次性任务的容器比如docker run alpine echo “Hello World”。echo命令执行完毕进程退出返回0。在Dockerfile中CMD [“sh”, “-c”, “./my_script.sh exit 0”]如果你的脚本成功执行并显式返回0。你的操作与排查通常无需排查。这是健康的行为。如果你发现一个应该长期运行的服务如Nginx、MySQL容器以退出码0停止那反而有问题说明服务进程自己正常退出了需要检查服务的日志和配置。3.2 退出码 1应用运行时错误含义这是一个“通用错误”代码。表示主进程因为应用程序自身的逻辑错误、配置错误或运行时异常而退出。这是最常见的一类非零退出码。典型场景脚本错误CMD指定的Shell脚本中存在语法错误如[1 -eq 1]缺少空格或引用了不存在的变量。命令未找到CMD [“python3”, “app.py”]但镜像里根本没有安装python3。应用启动失败你的Java应用因为类路径错误、端口被占用、配置文件缺失而启动失败。权限不足进程试图写入一个只读的目录或文件。实战排查步骤查看容器日志这是第一要务。docker logs container_id会打印出容器主进程的标准输出和标准错误错误信息通常一目了然。以交互模式运行对于复杂的启动问题可以尝试docker run -it --rm your_image sh进入容器内部然后手动执行你的启动命令直接观察错误输出。检查Dockerfile确保所有依赖的命令、文件、目录都存在且路径正确。检查文件权限如果你的应用需要写数据确保挂载的卷或容器内目录有正确的写权限。注意容器内进程通常以非root用户运行权限问题很常见。注意很多编程语言或框架有自己的非零退出码但“1”是其中最通用和常见的一个。看到退出码1首先想到的就是“看日志”。3.3 退出码 125Docker守护进程或CLI错误含义这个错误发生在Docker引擎自身而不是你的容器进程。它意味着docker run命令本身执行失败了容器甚至没有成功启动。典型场景无效的Dockerfile指令比如docker run了一个不存在的镜像名。权限问题用户没有执行docker命令的权限不在docker用户组。Docker守护进程未运行执行docker run时Docker服务daemon挂了。run命令参数错误使用了错误或冲突的docker run参数。实战排查步骤检查Docker服务状态systemctl status docker(Linux) 或查看Docker Desktop是否正常运行。检查命令和镜像名仔细核对docker run后的镜像名和标签是否正确。检查用户权限运行groups查看当前用户是否在docker组。如果不是可以用sudo前缀或将用户加入docker组sudo usermod -aG docker $USER需要重新登录。简化命令测试用一个最简单的命令测试如docker run --rm hello-world。如果连这个都失败那肯定是Docker环境本身的问题。3.4 退出码 126命令调用错误含义容器启动时指定的入口点ENTRYPOINT或命令CMD无法被调用执行。这通常是因为命令本身不存在或者它是一个文件但不可执行。典型场景命令拼写错误或不存在CMD [“/usr/bin/pythn”, “app.py”]python拼错了。文件权限不是可执行你写了一个Shell脚本start.sh作为CMD但在Dockerfile里忘记用chmod x start.sh给它执行权限。动态链接库缺失你编译了一个二进制文件但运行它的容器环境里缺少必要的glibc库或其他共享库。实战排查步骤进入镜像检查docker run -it --rm --entrypoint sh your_image然后手动尝试执行你在CMD中写的命令看报错信息。检查文件是否存在及路径使用which command或ls -la /path/to/command。检查文件权限ls -l查看文件确保有x执行权限。检查依赖库对于二进制文件可以在容器内用ldd /path/to/binary检查缺少哪些动态链接库。3.5 退出码 127命令未找到含义与126类似但更具体。Shell如/bin/sh在$PATH环境变量列出的所有目录中都找不到你要执行的命令。典型场景CMD [“myapp”]但myapp既不在系统默认路径如/usr/bin,/usr/local/bin下你也没有把它添加到PATH中或者没有把它复制到这些目录。在Shell脚本中调用了一个未安装的命令。与退出码126的区别126是“找到了文件但无法执行”127是“根本找不到这个命令文件”。127错误信息通常很明确/bin/sh: 1: myapp: not found。实战排查步骤确认命令在镜像中的位置构建镜像时确保你的可执行文件被放到了一个已知目录或者将其所在目录添加到PATH环境变量。使用绝对路径在CMD或ENTRYPOINT中尽量使用可执行文件的绝对路径避免依赖PATH。例如用CMD [“/usr/local/bin/myapp”]而不是CMD [“myapp”]。3.6 退出码 137 (SIGKILL) 与 143 (SIGTERM)进程被“杀死”这两个退出码直接关联Linux信号是理解容器被“杀”的关键。退出码 137 (128 9)含义容器主进程收到了SIGKILL(信号9) 信号。这个信号是不可捕获、不可阻塞的进程会立即被强制终止没有任何清理机会。典型场景最可能的原因内存不足OOM。这是生产环境中最常见的137退出码原因。当容器或宿主机内存不足时Linux内核的OOM Killer会选择一个“坏进程”并发送SIGKILL杀死它。Docker容器因为内存限制-m设置过低而触发的OOM是首要怀疑对象。手动强制杀死你执行了docker kill container命令不带信号参数默认就是SIGKILL。宿主机资源紧张宿主机整体内存耗尽内核OOM Killer杀死了容器进程。实战排查步骤针对OOM检查容器内存限制docker inspect container_id | grep -i memory。查看Memory和MemorySwap的值。检查宿主机内存free -h查看宿主机整体内存和Swap使用情况。查看内核日志在宿主机上执行dmesg -T | grep -i kill或journalctl -k | grep -i oom寻找OOM Killer杀死进程的记录里面通常包含进程ID和容器名。调整内存限制如果确认是OOM合理调整docker run时的-m参数或者优化应用本身的内存使用。退出码 143 (128 15)含义容器主进程收到了SIGTERM(信号15) 信号。这是一个优雅终止信号进程可以捕获这个信号并执行一些清理工作如关闭文件、保存状态、通知子进程后再退出。典型场景手动停止容器你执行了docker stop container。Docker会先发送SIGTERM等待一段时间默认为10秒让进程优雅关闭。如果超时进程还在Docker会再发送SIGKILL。编排工具缩容Kubernetes或Docker Swarm在停止Pod或服务副本时也会发送SIGTERM。宿机关机系统关机时init系统会向所有进程发送SIGTERM。你的操作退出码143通常是预期内的。如果你的应用需要更长时间进行清理可以通过docker stop -t seconds来延长等待时间。对于需要优雅关闭的应用确保它们正确实现了SIGTERM信号的处理逻辑。3.7 退出码 139 (SIGSEGV)段错误含义容器主进程收到了SIGSEGV(信号11) 信号对应退出码128 11 139。这表示进程进行了非法的内存访问比如试图写入只读内存、访问已释放的内存、或者数组越界等。这通常是应用程序存在严重Bug如C/C程序中的指针错误的迹象。典型场景编译型语言C/C/Rust的程序存在内存操作Bug。某些解释型语言如Python通过C扩展的底层模块存在缺陷。硬件或内核驱动不稳定较少见。实战排查步骤这是应用层Bug首先明确这基本不是Docker或系统配置问题而是你运行的程序本身有缺陷。查看核心转储如果容器和宿主机配置允许生成核心转储core dump可以获取并用于调试。但这在容器环境中通常比较麻烦需要挂载/proc/sys/kernel/core_pattern并设置足够的权限。简化复现尝试在宿主机或一个更简单的容器环境中复现问题排除是特定Docker环境导致的偶发问题。检查应用日志应用在崩溃前可能会在日志中留下线索。使用调试工具如果可能在带有调试符号的版本中使用gdb等工具运行程序来定位崩溃点。3.8 其他基于信号的常见退出码除了上述几个其他由信号导致的退出码也遵循128 信号编号的规则退出码 130 (128 2)对应SIGINT。通常由用户在终端按CtrlC中断容器进程在docker run -it交互模式下产生。退出码 255这个码有点特殊。有时它可能表示状态码超出了0-255的范围在Shell中退出码通常被限制在这个范围。但在Docker上下文中它也可能是一些特定运行时如Java JVM在遇到严重错误时返回的。需要结合日志具体分析。4. 系统化排查指南当容器退出时你该怎么做面对一个退出的容器遵循一套系统的排查流程能帮你快速定位问题。下面是我的实战 checklist4.1 第一步获取退出码和基本信息# 查看所有容器状态找到退出的那个 docker ps -a # 查看特定容器的详细信息包括退出码、启动命令、运行时间等 docker inspect container_id --format{{.State.ExitCode}} {{.State.Error}} {{.Config.Cmd}} {{.State.StartedAt}} {{.State.FinishedAt}}4.2 第二步查看容器日志首要步骤# 查看容器的全部日志 docker logs container_id # 查看容器最新的N行日志 docker logs --tail 100 container_id # 实时查看日志对排查启动问题很有用但容器已退出则无效 # docker logs -f container_id日志是解决“退出码1、126、127”等问题的最直接证据。4.3 第三步结合退出码进行针对性分析根据上面章节的指南对号入座退出码 1重点看应用日志检查配置和依赖。退出码 125/126/127检查Dockerfile、命令路径和文件权限。退出码 137检查内存限制和宿主机内存状况查内核日志 (dmesg)。退出码 139定位应用本身的Bug。退出码 143通常是正常停止检查是否为预期行为。4.4 第四步复现与调试如果通过日志无法确定尝试复现问题# 1. 以交互模式启动并覆盖原来的命令进入shell docker run -it --rm --entrypoint sh your_image:tag # 2. 在容器内手动执行你的启动命令 /path/to/your/command --with-args # 3. 观察错误输出进行调试4.5 第五步检查宿主机与Docker环境对于125、137等涉及Docker本身或宿主机资源的问题docker info或docker version检查Docker状态和版本。systemctl status docker检查Docker服务。free -h、df -h、dmesg -T检查宿主机资源内存、磁盘、内核消息。5. 高级技巧与预防措施5.1 在Dockerfile中主动管理退出码一个好的应用应该明确地返回有意义的退出码。你可以在Dockerfile的脚本或应用的关闭逻辑中控制它。# 示例在Shell脚本中捕获信号并优雅退出 #!/bin/sh # trap.sh cleanup() { echo “收到信号正在清理...” # 执行清理任务 exit 0 # 清理后返回0 } trap cleanup SIGTERM SIGINT echo “应用启动...” # 模拟一个长期运行的任务 sleep infinity然后在Dockerfile中COPY trap.sh / RUN chmod x /trap.sh CMD [“/trap.sh”]这样当收到docker stop发送的SIGTERM时容器会执行清理并返回退出码0而不是143。5.2 使用docker run的--init参数对于可能产生僵尸进程的应用可以使用--init参数。它会使用一个轻量级的init进程如tini作为PID 1这个init进程会正确地转发信号并回收僵尸进程使得信号处理和进程停止行为更符合预期。docker run --init your_image5.3 合理设置资源限制与重启策略内存限制根据应用实际需求通过-m、--memory-swap设置合理的内存限制避免OOM Killer误杀。可以设置得稍有余量。重启策略利用--restart策略让Docker在容器非正常退出时自动重启。--restart no默认不重启。--restart on-failure[:max-retries]仅在非0退出码时重启可指定最大重试次数。--restart always总是重启无论退出码是什么。--restart unless-stopped总是重启除非用户显式执行docker stop。例如对于一个需要高可用的Web服务docker run -d --name my-web --restart unless-stopped -p 80:80 my-web-app5.4 监控与告警在生产环境中将容器的退出码尤其是非0和非143的码纳入监控和告警体系。可以通过以下方式Docker事件监控docker events --filter ‘eventdie’可以实时监听容器停止事件并获取退出码。编排平台监控如果你使用KubernetesPod的状态CrashLoopBackOff和容器的lastState.terminated.exitCode是关键的监控指标。日志聚合将docker logs输出的内容发送到ELK、Loki等日志平台方便搜索和分析。容器退出码是一个连接Docker操作与底层Linux系统行为的桥梁。花时间理解它绝不是纸上谈兵而是实实在在能提升你运维和调试效率的技能。下次再遇到容器异常退出别再盲目搜索了先看一眼退出码按照本文的排查思路走一遍你可能会发现问题解决起来比想象中要简单得多。记住docker logs是你的第一把钥匙而退出码则是告诉你该用哪把钥匙去开哪扇门的门牌号。 
长河君 · 2026/8/13 7:39:18 · 阅读 1.2k Docker容器退出码全解析：从Linux进程信号到实战排查指南
1. 项目概述为什么Docker退出码值得你花时间研究如果你用过Docker大概率遇到过容器运行着运行着就自己停了的情况。这时候你第一反应可能是docker ps -a看一眼然后发现容器状态是Exited (137)或者Exited (1)。这个括号里的数字就是Docker容器的退出码。它就像容器临终前留下的“遗言”告诉你它到底是怎么“死”的。但很多人看到这个数字第一反应是去搜索引擎里搜“Docker 137错误”而不是去理解这个数字背后的含义。我刚开始用Docker时也这样每次容器异常退出都像在解谜到处找零散的解决方案。直到后来系统地梳理了一遍才发现这些退出码背后有一套清晰的逻辑掌握了它排查问题的效率能提升好几个数量级。这不仅仅是Docker的知识更是Linux进程信号和系统调用返回值的核心体现。今天我就把自己踩过的坑和总结的经验掰开揉碎了讲给你听让你下次再看到退出码时能胸有成竹快速定位根因。2. 退出码的本质容器只是进程的包装要理解Docker退出码首先得抛开“容器”这个抽象概念回到最根本的计算机原理上。一个正在运行的Docker容器本质上就是一个或多个在隔离环境Namespace、Cgroups中运行的Linux进程。容器的“主进程”通常就是你在Dockerfile里用CMD或ENTRYPOINT指定的那个命令。当这个主进程结束时整个容器的使命也就完成了容器随之停止。而进程结束时会向操作系统返回一个整数值这个值就是退出状态码。在Linux/Unix世界里这几乎是一个铁律进程结束必须有一个退出码。Docker做的只是把这个底层操作系统的退出码捕获出来原封不动地展示给你看。所以docker run命令的返回值以及docker ps -a里显示的Exited (xxx)就是这个主进程的退出码。理解这一点至关重要它意味着所有Linux进程的退出码规则都适用于Docker容器。比如0代表成功非0代表失败。排查Docker容器退出问题很大程度上就是在排查这个主进程为什么以及如何退出的。很多退出码直接对应着Linux内核发送给进程的信号。进程被信号杀死时退出码通常是128 信号编号。3. 常见退出码深度解析与实战应对下面我们来逐一拆解那些让你头疼的常见退出码。我会结合具体场景、命令和排查思路让你不仅知道“是什么”更明白“为什么”和“怎么办”。3.1 退出码 0正常退出含义这是最理想的退出状态表示容器内的主进程按照预期正常结束任务已完成。典型场景运行一个一次性任务的容器比如docker run alpine echo “Hello World”。echo命令执行完毕进程退出返回0。在Dockerfile中CMD [“sh”, “-c”, “./my_script.sh exit 0”]如果你的脚本成功执行并显式返回0。你的操作与排查通常无需排查。这是健康的行为。如果你发现一个应该长期运行的服务如Nginx、MySQL容器以退出码0停止那反而有问题说明服务进程自己正常退出了需要检查服务的日志和配置。3.2 退出码 1应用运行时错误含义这是一个“通用错误”代码。表示主进程因为应用程序自身的逻辑错误、配置错误或运行时异常而退出。这是最常见的一类非零退出码。典型场景脚本错误CMD指定的Shell脚本中存在语法错误如[1 -eq 1]缺少空格或引用了不存在的变量。命令未找到CMD [“python3”, “app.py”]但镜像里根本没有安装python3。应用启动失败你的Java应用因为类路径错误、端口被占用、配置文件缺失而启动失败。权限不足进程试图写入一个只读的目录或文件。实战排查步骤查看容器日志这是第一要务。docker logs container_id会打印出容器主进程的标准输出和标准错误错误信息通常一目了然。以交互模式运行对于复杂的启动问题可以尝试docker run -it --rm your_image sh进入容器内部然后手动执行你的启动命令直接观察错误输出。检查Dockerfile确保所有依赖的命令、文件、目录都存在且路径正确。检查文件权限如果你的应用需要写数据确保挂载的卷或容器内目录有正确的写权限。注意容器内进程通常以非root用户运行权限问题很常见。注意很多编程语言或框架有自己的非零退出码但“1”是其中最通用和常见的一个。看到退出码1首先想到的就是“看日志”。3.3 退出码 125Docker守护进程或CLI错误含义这个错误发生在Docker引擎自身而不是你的容器进程。它意味着docker run命令本身执行失败了容器甚至没有成功启动。典型场景无效的Dockerfile指令比如docker run了一个不存在的镜像名。权限问题用户没有执行docker命令的权限不在docker用户组。Docker守护进程未运行执行docker run时Docker服务daemon挂了。run命令参数错误使用了错误或冲突的docker run参数。实战排查步骤检查Docker服务状态systemctl status docker(Linux) 或查看Docker Desktop是否正常运行。检查命令和镜像名仔细核对docker run后的镜像名和标签是否正确。检查用户权限运行groups查看当前用户是否在docker组。如果不是可以用sudo前缀或将用户加入docker组sudo usermod -aG docker $USER需要重新登录。简化命令测试用一个最简单的命令测试如docker run --rm hello-world。如果连这个都失败那肯定是Docker环境本身的问题。3.4 退出码 126命令调用错误含义容器启动时指定的入口点ENTRYPOINT或命令CMD无法被调用执行。这通常是因为命令本身不存在或者它是一个文件但不可执行。典型场景命令拼写错误或不存在CMD [“/usr/bin/pythn”, “app.py”]python拼错了。文件权限不是可执行你写了一个Shell脚本start.sh作为CMD但在Dockerfile里忘记用chmod x start.sh给它执行权限。动态链接库缺失你编译了一个二进制文件但运行它的容器环境里缺少必要的glibc库或其他共享库。实战排查步骤进入镜像检查docker run -it --rm --entrypoint sh your_image然后手动尝试执行你在CMD中写的命令看报错信息。检查文件是否存在及路径使用which command或ls -la /path/to/command。检查文件权限ls -l查看文件确保有x执行权限。检查依赖库对于二进制文件可以在容器内用ldd /path/to/binary检查缺少哪些动态链接库。3.5 退出码 127命令未找到含义与126类似但更具体。Shell如/bin/sh在$PATH环境变量列出的所有目录中都找不到你要执行的命令。典型场景CMD [“myapp”]但myapp既不在系统默认路径如/usr/bin,/usr/local/bin下你也没有把它添加到PATH中或者没有把它复制到这些目录。在Shell脚本中调用了一个未安装的命令。与退出码126的区别126是“找到了文件但无法执行”127是“根本找不到这个命令文件”。127错误信息通常很明确/bin/sh: 1: myapp: not found。实战排查步骤确认命令在镜像中的位置构建镜像时确保你的可执行文件被放到了一个已知目录或者将其所在目录添加到PATH环境变量。使用绝对路径在CMD或ENTRYPOINT中尽量使用可执行文件的绝对路径避免依赖PATH。例如用CMD [“/usr/local/bin/myapp”]而不是CMD [“myapp”]。3.6 退出码 137 (SIGKILL) 与 143 (SIGTERM)进程被“杀死”这两个退出码直接关联Linux信号是理解容器被“杀”的关键。退出码 137 (128 9)含义容器主进程收到了SIGKILL(信号9) 信号。这个信号是不可捕获、不可阻塞的进程会立即被强制终止没有任何清理机会。典型场景最可能的原因内存不足OOM。这是生产环境中最常见的137退出码原因。当容器或宿主机内存不足时Linux内核的OOM Killer会选择一个“坏进程”并发送SIGKILL杀死它。Docker容器因为内存限制-m设置过低而触发的OOM是首要怀疑对象。手动强制杀死你执行了docker kill container命令不带信号参数默认就是SIGKILL。宿主机资源紧张宿主机整体内存耗尽内核OOM Killer杀死了容器进程。实战排查步骤针对OOM检查容器内存限制docker inspect container_id | grep -i memory。查看Memory和MemorySwap的值。检查宿主机内存free -h查看宿主机整体内存和Swap使用情况。查看内核日志在宿主机上执行dmesg -T | grep -i kill或journalctl -k | grep -i oom寻找OOM Killer杀死进程的记录里面通常包含进程ID和容器名。调整内存限制如果确认是OOM合理调整docker run时的-m参数或者优化应用本身的内存使用。退出码 143 (128 15)含义容器主进程收到了SIGTERM(信号15) 信号。这是一个优雅终止信号进程可以捕获这个信号并执行一些清理工作如关闭文件、保存状态、通知子进程后再退出。典型场景手动停止容器你执行了docker stop container。Docker会先发送SIGTERM等待一段时间默认为10秒让进程优雅关闭。如果超时进程还在Docker会再发送SIGKILL。编排工具缩容Kubernetes或Docker Swarm在停止Pod或服务副本时也会发送SIGTERM。宿机关机系统关机时init系统会向所有进程发送SIGTERM。你的操作退出码143通常是预期内的。如果你的应用需要更长时间进行清理可以通过docker stop -t seconds来延长等待时间。对于需要优雅关闭的应用确保它们正确实现了SIGTERM信号的处理逻辑。3.7 退出码 139 (SIGSEGV)段错误含义容器主进程收到了SIGSEGV(信号11) 信号对应退出码128 11 139。这表示进程进行了非法的内存访问比如试图写入只读内存、访问已释放的内存、或者数组越界等。这通常是应用程序存在严重Bug如C/C程序中的指针错误的迹象。典型场景编译型语言C/C/Rust的程序存在内存操作Bug。某些解释型语言如Python通过C扩展的底层模块存在缺陷。硬件或内核驱动不稳定较少见。实战排查步骤这是应用层Bug首先明确这基本不是Docker或系统配置问题而是你运行的程序本身有缺陷。查看核心转储如果容器和宿主机配置允许生成核心转储core dump可以获取并用于调试。但这在容器环境中通常比较麻烦需要挂载/proc/sys/kernel/core_pattern并设置足够的权限。简化复现尝试在宿主机或一个更简单的容器环境中复现问题排除是特定Docker环境导致的偶发问题。检查应用日志应用在崩溃前可能会在日志中留下线索。使用调试工具如果可能在带有调试符号的版本中使用gdb等工具运行程序来定位崩溃点。3.8 其他基于信号的常见退出码除了上述几个其他由信号导致的退出码也遵循128 信号编号的规则退出码 130 (128 2)对应SIGINT。通常由用户在终端按CtrlC中断容器进程在docker run -it交互模式下产生。退出码 255这个码有点特殊。有时它可能表示状态码超出了0-255的范围在Shell中退出码通常被限制在这个范围。但在Docker上下文中它也可能是一些特定运行时如Java JVM在遇到严重错误时返回的。需要结合日志具体分析。4. 系统化排查指南当容器退出时你该怎么做面对一个退出的容器遵循一套系统的排查流程能帮你快速定位问题。下面是我的实战 checklist4.1 第一步获取退出码和基本信息# 查看所有容器状态找到退出的那个 docker ps -a # 查看特定容器的详细信息包括退出码、启动命令、运行时间等 docker inspect container_id --format{{.State.ExitCode}} {{.State.Error}} {{.Config.Cmd}} {{.State.StartedAt}} {{.State.FinishedAt}}4.2 第二步查看容器日志首要步骤# 查看容器的全部日志 docker logs container_id # 查看容器最新的N行日志 docker logs --tail 100 container_id # 实时查看日志对排查启动问题很有用但容器已退出则无效 # docker logs -f container_id日志是解决“退出码1、126、127”等问题的最直接证据。4.3 第三步结合退出码进行针对性分析根据上面章节的指南对号入座退出码 1重点看应用日志检查配置和依赖。退出码 125/126/127检查Dockerfile、命令路径和文件权限。退出码 137检查内存限制和宿主机内存状况查内核日志 (dmesg)。退出码 139定位应用本身的Bug。退出码 143通常是正常停止检查是否为预期行为。4.4 第四步复现与调试如果通过日志无法确定尝试复现问题# 1. 以交互模式启动并覆盖原来的命令进入shell docker run -it --rm --entrypoint sh your_image:tag # 2. 在容器内手动执行你的启动命令 /path/to/your/command --with-args # 3. 观察错误输出进行调试4.5 第五步检查宿主机与Docker环境对于125、137等涉及Docker本身或宿主机资源的问题docker info或docker version检查Docker状态和版本。systemctl status docker检查Docker服务。free -h、df -h、dmesg -T检查宿主机资源内存、磁盘、内核消息。5. 高级技巧与预防措施5.1 在Dockerfile中主动管理退出码一个好的应用应该明确地返回有意义的退出码。你可以在Dockerfile的脚本或应用的关闭逻辑中控制它。# 示例在Shell脚本中捕获信号并优雅退出 #!/bin/sh # trap.sh cleanup() { echo “收到信号正在清理...” # 执行清理任务 exit 0 # 清理后返回0 } trap cleanup SIGTERM SIGINT echo “应用启动...” # 模拟一个长期运行的任务 sleep infinity然后在Dockerfile中COPY trap.sh / RUN chmod x /trap.sh CMD [“/trap.sh”]这样当收到docker stop发送的SIGTERM时容器会执行清理并返回退出码0而不是143。5.2 使用docker run的--init参数对于可能产生僵尸进程的应用可以使用--init参数。它会使用一个轻量级的init进程如tini作为PID 1这个init进程会正确地转发信号并回收僵尸进程使得信号处理和进程停止行为更符合预期。docker run --init your_image5.3 合理设置资源限制与重启策略内存限制根据应用实际需求通过-m、--memory-swap设置合理的内存限制避免OOM Killer误杀。可以设置得稍有余量。重启策略利用--restart策略让Docker在容器非正常退出时自动重启。--restart no默认不重启。--restart on-failure[:max-retries]仅在非0退出码时重启可指定最大重试次数。--restart always总是重启无论退出码是什么。--restart unless-stopped总是重启除非用户显式执行docker stop。例如对于一个需要高可用的Web服务docker run -d --name my-web --restart unless-stopped -p 80:80 my-web-app5.4 监控与告警在生产环境中将容器的退出码尤其是非0和非143的码纳入监控和告警体系。可以通过以下方式Docker事件监控docker events --filter ‘eventdie’可以实时监听容器停止事件并获取退出码。编排平台监控如果你使用KubernetesPod的状态CrashLoopBackOff和容器的lastState.terminated.exitCode是关键的监控指标。日志聚合将docker logs输出的内容发送到ELK、Loki等日志平台方便搜索和分析。容器退出码是一个连接Docker操作与底层Linux系统行为的桥梁。花时间理解它绝不是纸上谈兵而是实实在在能提升你运维和调试效率的技能。下次再遇到容器异常退出别再盲目搜索了先看一眼退出码按照本文的排查思路走一遍你可能会发现问题解决起来比想象中要简单得多。记住docker logs是你的第一把钥匙而退出码则是告诉你该用哪把钥匙去开哪扇门的门牌号。