退出码137表示进程被SIGKILL（信号9）终止，只可能是kill -9或OOM Killer所为；需立即执行dmesg -T | grep -i "killed process"查内核日志确认是否OOM触发。
看退出码：先确认是不是被信号杀的
进程退出后立刻执行 echo $?，结果不是 0 就说明异常退出。关键看是不是 128+信号编号——比如 137 就是 SIGKILL（信号 9），143 是 SIGTERM（信号 15）。这一步能快速排除是程序自己崩溃还是被外部干预。
-
134→SIGABRT：大概率是代码里调了abort()或断言失败 -
139→SIGSEGV：访问非法内存，比如空指针解引用、数组越界 -
137→SIGKILL：不能被捕获，只可能是kill -9或 OOM Killer 动的手
dmesg 查 OOM Killer：内存不够时最常被忽略的源头
OOM Killer 的日志只存在内核环形缓冲区里，journalctl 和系统日志通常不记全。必须用 dmesg：
-
dmesg -T | grep -i "killed process"—— 最直接匹配 -
dmesg -T | grep -i "oom"—— 看有没有整段内存压力分析 - 如果输出为空，不代表没发生过：内核日志可能已被刷掉，需提前配置
kernel.dmesg_restrict=0并增大kernel.msgmax
典型输出里会带进程名、PID、内存占用（total-vm、anon-rss）和触发时的可用内存值，这是判断是否真因内存不足的唯一硬依据。
查 syslog/journalctl：找人为 kill 或 systemd 干预痕迹
如果是人或脚本发的 kill、systemctl stop，或者 systemd 因配置问题主动终止服务，这些会在用户空间日志里留下记录：
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- Ubuntu/Debian：
grep -i "killed process" /var/log/syslog - RHEL/CentOS：
grep -i "killed process" /var/log/messages - systemd 管理的服务：
journalctl -u your-service.service --since "1 hour ago" | grep -E "(killed|signal|exit)"
注意：普通 kill -15 不一定留痕；但 systemctl stop、systemd 的自动重启失败、Restart=on-failure 触发的反复退出，都会在 journal 里写清楚原因和退出码。
auditd 审计 kill 调用：只有 root 能查到谁动的手
想确认是不是有人（或某个脚本）显式执行了 kill 或 killall，得靠 auditd 记录系统调用：
- 先确保 auditd 运行：
systemctl status auditd - 加规则监控 kill 系统调用：
auditctl -a always,exit -F arch=b64 -S kill -F pid=12345（把 12345 换成目标 PID） - 查日志：
ausearch -m avc -ts recent | grep kill或ausearch -sc kill -i
这个方法不会捕获 OOM Killer 或内核自发行为，但它能明确告诉你哪个 UID、哪个可执行文件、在什么时间调用了 kill 系统调用——对排查误操作或恶意脚本最有效。
真正难定位的是那些没留日志的场景：比如 cgroup 内存限制被硬性触发、磁盘满导致 coredump 失败连带 kill 进程、或父进程静默退出引发子进程被 init 收养后又退出。这些往往要结合 cat /proc/PID/status（看 PPid、CapEff）、systemd-cgtop 和 df -h 交叉验证。
