dmesg -T | grep -A5 -B5 "Killed process"是诊断OOM Killer杀进程的最可靠方法，因其直接读取内核ring buffer中唯一一次的关键记录，含PID、进程名、anon-rss等关键内存指标，并需结合上下文判断是否真为OOM触发。
进程被内核强杀（比如 SIGKILL）几乎总是源于内核主动干预，最常见的是 OOM Killer 触发。直接看 dmesg 输出是最可靠、最快捷的路径，其他日志（如 journalctl）可能延迟或缺失关键上下文。
查 dmesg 里 “Killed process” 记录
OOM Killer 的日志只写进内核环形缓冲区，dmesg 是唯一能原样看到它的命令。系统日志（/var/log/syslog 或 journalctl）往往漏掉或截断内存用量细节。
- 运行
dmesg -T | grep -A5 -B5 "Killed process"：带时间戳，前后各 5 行，方便定位上下文 - 如果输出为空，说明不是 OOM Killer 杀的，而是人为
kill -9或其他信号 —— 此时需转向审计日志（auditd） - 注意日志里的
total-vm和anon-rss：前者是虚拟内存总量，后者是实际占用的物理内存（含 swap），若anon-rss接近机器总内存，基本锁定 OOM - 别信
journalctl --since "1 hour ago" | grep oom：systemd 日志可能没同步内核事件，尤其在高负载下
区分 SIGKILL 是内核发的还是人发的
SIGKILL（信号 9）本身不可捕获、不可忽略，但来源不同，排查手段完全不同。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 内核发出的
SIGKILL：只来自 OOM Killer，必定伴随dmesg中 “Out of memory” 和 “Killed process” 字样 - 用户/脚本发出的
kill -9：dmesg不记录，需启用auditd并配置规则：auditctl -a always,exit -F arch=b64 -S kill -F a1=9 -
systemd发的SIGKILL：通常因超时（如TimeoutSec到期），查journalctl -u your.service，找 “killing process” 或 “sending SIGKILL” 行 - 容器环境（如 Docker）：宿主机
dmesg仍有效，但 PID 是宿主机视角；容器内ps看到的 PID 与日志中不一致，需用docker inspect查State.Pid
状态码 137 就等于 OOM Killer 杀的
shell 中执行完程序立刻运行 echo $?，得到 137 → 等价于 128 + 9，即收到 SIGKILL。结合 dmesg 有无 OOM 记录，就能 100% 确认。
- 137：基本可断定是 OOM Killer（除非你刚手动
kill -9且没清日志） - 139：不是内核强杀，是进程自己触发段错误（
SIGSEGV），查core dump或strace - 143：
SIGTERM，通常是systemctl stop或kill（非 -9），进程有机会清理后退出 - 注意：某些 shell（如
zsh）对子 shell 退出码处理略有差异，务必在目标进程父 shell 中立即执行echo $?
真正容易被忽略的点是：OOM Killer 日志可能被刷出缓冲区。如果机器重启过，dmesg 默认只保留最近一次启动的日志；要用 dmesg -T --file /var/log/kern.log（如果启用了 rsyslog 写入）或提前配置 kernel.dmesg_restrict=0 并定期归档。
