linux 进程异常退出，通常不是“直接消失”，而是留下了可追溯的线索。关键在于快速定位是被谁、因何、在何时终止——是程序自身崩溃？被系统 OOM Killer 杀掉？收到信号后未处理？还是 systemd 主动重启失败？下面从几个高频场景切入，帮你高效排查。
看退出码和日志：第一时间确认“怎么死的”
进程退出后，shell 中执行 $? 可查上一个命令的退出状态码（0 表示成功，非 0 通常代表异常）。但仅靠这个不够，得结合日志：
- 如果是 systemd 管理的服务，用 journalctl -u your-service.service -n 100 -o cat 查最近日志，重点关注 Error、segfault、Killed、signal 等关键词；
- 普通后台进程若重定向了 stdout/stderr（如 > /var/log/myapp.log 2>&1），直接查看对应日志文件；
- 没有日志？临时加 strace -f -e trace=signal,exit_group -o /tmp/trace.log ./your-program 运行，能捕获所有信号和退出调用。
查是否被 OOM Killer 终止：内存不足的典型表现
进程突然消失且日志里出现 “Killed process XXX (xxx) total-vm:XXXXkB, anon-rss:XXXXkB, file-rss:0kB”，基本就是 OOM Killer 下的手。验证方法：
- 运行 dmesg -T | grep -i “killed process”，看是否有匹配记录；
- 检查系统内存压力：free -h、cat /proc/meminfo | grep -E “MemAvailable|SwapFree”；
- 确认该进程的内存使用趋势：pidstat -r -p $(pgrep your-process) 1（需提前知道 PID）或用 systemd-cgtop 查 cgroup 内存限制。
分析信号来源：谁发了 SIGTERM/SIGKILL？
很多“异常退出”其实是收到了信号。常见情况包括：
- SIGTERM（15）：常由 systemctl stop、kill 命令、父进程或监控脚本发起；用 auditctl -a always,exit -F arch=b64 -S kill -F pid=your-pid 可审计 kill 调用（需 auditd 开启）；
- SIGKILL（9）：无法被捕获或忽略，通常是 OOM Killer 或 root 手动 kill -9；
- SIGSEGV/SIGABRT：程序自身缺陷导致，配合 coredumpctl debug your-process（需开启 coredump）可加载 core 文件调试；
- 检查进程是否设置了 signal handler：用 cat /proc/pid/status | grep Sig 查当前阻塞/忽略的信号位图（需在退出前抓取）。
检查 systemd 配置与依赖：自动退出不一定是代码问题
服务启动后秒退，很可能是 systemd 认为它“没跑起来”。重点检查：
- Type= 设置是否匹配实际行为：Type=simple（默认）要求主进程不 daemonize；若程序自己 fork 后退出前台，应设为 Type=forking，并配好 PIDFile；
- Restart= 和 RestartSec= 是否掩盖了真实失败？临时改为 Restart=no 并手动 systemctl start，观察首次启动是否报错；
- 依赖项缺失：systemctl list-dependencies –reverse your-service.service 查反向依赖，再用 systemctl status 看依赖单元是否 active；
- 环境变量或工作目录错误：systemctl show your-service.service | grep -E “(Environment|WorkingDirectory|ExecStart)” 核对路径和变量是否真实存在。
不复杂但容易忽略——多数异常退出背后，是日志没开、信号没捕获、内存没限、配置没对齐。动手前先问一句：它上次正常运行时，和现在差了哪一点？