Linux 守护进程异常退出的定位方法

排查 systemd 服务异常需先运行 systemctl status 查 Active 状态及退出码/信号，再用 journalctl -u -n 50 -o cat 查日志；注意 Restart= 策略掩盖错误、OOM Killer 静默杀进程（dmesg 验证）、守护进程退出码与信号捕获、fd/权限/工作目录限制，以及多条件叠加导致的循环失败。

查 systemd 服务状态和最近日志

绝大多数现代 linux 发行版用 systemd 管理守护进程，异常退出后第一反应不是翻应用日志，而是看 systemd 是否记录了启动失败、被杀或崩溃信号。

• 运行 systemctl status your-service-name，重点看 Active: 行是否为 failed，以及末尾几行的 Process exited with code 或 Killed by signal
• 用 journalctl -u your-service-name -n 50 --no-pager 查最近 50 行日志；若服务已退出，加 -o cat 避免转义控制字符，更易读
• 注意 systemd 的 Restart= 策略（如 on-failure）可能导致频繁重启，掩盖原始错误——此时 journalctl 会显示多段“Started → Stopped”循环

确认进程是否被 OOM Killer 杀掉

内存耗尽时，内核会静默杀死占用最多内存的进程，不经过 systemd 正常终止流程，只在 dmesg 留下痕迹。

• 执行 dmesg -T | grep -i "killed process"，若输出类似 [Wed Jan 10 14:22:33 2024] Killed process 12345 (mydaemon) total-vm:2456784kB, anon-rss:1890123kB，基本可定性为 OOM
• 检查 /proc/PID/status 中的 OOMScoreAdj 值（越正越容易被杀），以及容器环境是否设置了 memory.limit_in_bytes
• 临时验证：用 echo -17 > /proc/PID/oom_score_adj 降低该进程被杀优先级（仅调试用，勿写入生产配置）

检查守护进程自身退出码和信号捕获

很多守护进程在初始化失败（如端口被占、配置文件语法错）时直接调用 exit(1) 或触发 SigsEGV，但没打印足够上下文。

• 在服务 unit 文件中临时添加 Environment=LD_DEBUG=files,libs 和 StandardOutput=journal+console，让动态链接和标准输出强制进 journal
• 若怀疑是信号导致退出，用 strace -f -p PID 2>&1 | grep -E "(exit|kill|sig)" 实时抓取（需在进程启动后立刻 attach）
• 检查代码中是否忽略 SIGPIPE（常见于日志写入断开时）或未处理 SIGHUP（某些 systemd 版本在 reload 时会发）

验证文件描述符、权限与工作目录限制

守护进程 fork 后常切换用户、chdir 到 /、关闭所有 fd，这些操作若失败，会导致静默退出且无有效日志。

• 用 systemctl show your-service-name | grep -E "(LimitNOFILE|WorkingDirectory|User|NoNewPrivileges)" 核对关键限制项
• 若服务以非 root 用户运行，检查其能否访问配置文件（stat -c "%U:%G %a %n" /path/to/conf）、证书路径、socket 文件父目录等
• LimitNOFILE 过低（如默认 1024）可能使高并发服务在 accept 新连接时 open() 失败并退出——改 LimitNOFILE=65536 并重载 unit

真正难定位的往往是多个条件叠加：比如 OOM Killer 杀进程后，systemd 因 RestartSec=100ms 快速重启，新进程又因残留锁文件或端口未释放而立即失败，形成“启动→退出→重启”死循环。这时候得关掉自动重启，手动跑一次带完整 strace 和环境变量的命令，才能看到第一手失败原因。