Linux怎么查看具体的进程被强制杀掉原因表

退出码137表示进程被SIGKILL（信号9）强制终止，原因不限于OOM，还可能是手动kill、systemd终止或cgroup内存超限；需结合dmesg日志、OOMKilled标记及auditd审计综合定位真实源头。

进程退出码 137 就是 SIGKILL，但不等于 OOM

很多人一看到 echo $? 返回 137，下意识就会把原因归到“OOM Killer”，但这其实并不准确。137 真正表达的是：进程收到了 SIGKILL（信号值 9，128+9=137）。而这个信号有个关键特点——不可捕获、不可忽略。它的来源并不只有一种，常见情况包括：
• 用户手动执行了 kill -9
• systemd 或容器运行时主动终止（如超时、健康检查失败）
• OOM Killer 触发
• 容器 cgroup 内存超限后内核强制杀进程（日志里会写 Memory cgroup out of memory，不是普通 OOM）
说白了，退出码只能说明“进程是被杀掉的”，却不能直接告诉你“是谁动的手”。真正要定位源头，还是得结合上下文一起看。

dmesg -T | grep "killed process" 是唯一能确认 OOM Killer 的方式

内核只在 ring buffer 里写一次 OOM 关键记录，dmesg 是唯一能原样读到它的工具。
• 必须用 sudo：RHEL 8+/CentOS 8+ 默认 kernel.dmesg_restrict=1，非 root 看不到完整内容
• 一定要加 -T：不加就是 [12345.678901] 这种相对时间，根本没法和你发现进程挂掉的时间对齐
• 典型输出：[Wed Apr 10 09:22:17 2026] Killed process 18942 (python3) total-vm:4567890kB, anon-rss:3214567kB
• 关键看 anon-rss：它代表真实占用的物理内存（不含缓存/文件映射），如果接近机器总内存，基本坐实是它撑爆了系统

查不到 "killed process" 不代表没发生，优先检查三件事

日志被刷掉或权限受限很常见，别直接放弃：
• 运行 sudo sysctl kernel.dmesg_restrict，返回 1 就说明被限制，临时放开：sudo sysctl kernel.dmesg_restrict=0
• 检查 /var/log/messages 或 journalctl -k：部分发行版会落盘 OOM 日志，命令是 sudo grep -i "out of memory|killed process" /var/log/messages
• 拉最近 200 行内核日志：sudo dmesg -T | tail -n 200，人工扫 OOM 时间点前后 5 秒——真正线索常藏在 page allocation failure 或 low memory 这类前置提示里

想定位谁发的 kill -9，得靠 auditd 记录 syscall

单靠内核日志，其实看不出到底是哪个用户、哪个进程触发了 kill() 系统调用。真要把这件事查清楚，还得把审计子系统启用起来：
• 先开启 auditd：sudo systemctl enable --now auditd
• 再添加规则，专门监听 kill 调用：sudo auditctl -a always,exit -F arch=b64 -S kill -F a1=9（这里的 a1=9，对应的就是信号 SIGKILL）
• 接着查日志：sudo ausearch -sc kill | grep -A5 -B5 "comm="，输出结果里的 comm= 表示发起调用的进程名，exe= 表示二进制路径，uid= 则是发起者的用户 ID
• 另外要注意，auditd 不会记录容器内部发起的 kill 行为，它只记录宿主机上产生的调用

OOM Killer 的决策依据是 oom_score_adj 值，不是单纯看 RSS 大小；而容器场景下，cgroup 限额比整机内存更关键——这两点最容易被忽略。