生产环境Linux下C++守护进程异常重启的排查与调试方法咨询

这种生产环境下的无头Crash问题我处理过不少，核心思路就是尽量不干扰业务运行，先抓现场再离线分析。下面一步步给你说可行的方案：

先从系统层面挖线索，不用碰进程本身：

• 查系统全局日志：直接搜/var/log/syslog或/var/log/messages（不同发行版路径可能有差异），用命令grep "你的进程名" /var/log/syslog过滤。重点找segmentation fault、aborted、killed这类关键词——很多时候进程异常退出会被系统内核记录，比如是收到了SIGSEGV信号，或是被OOM Killer干掉的。
• 检查systemd日志（如果进程由systemd管理）：用journalctl -u 你的服务名.service，systemd会记录进程的启动/退出状态码、触发退出的信号，甚至能抓到进程的stdout/stderr输出（如果之前没配置日志，可临时修改service文件的StandardOutput=journal+console，改完执行systemctl daemon-reload && systemctl restart 服务名，这个操作会重启一次进程，但影响很小）。
• 监控资源使用：用pidstat -p <进程PID> 1每秒采样一次进程的CPU、内存、IO数据，看是不是内存持续上涨导致OOM？或是某个时刻CPU突然飙升后崩溃？也可以用top持续观察进程状态。
• 检查文件描述符：执行lsof -p <进程PID>，看进程打开的文件、套接字数量，有没有句柄泄漏，或是打开了某个失效的文件/套接字？

核心转储是最有用的现场数据，而且可以做到低侵入甚至无侵入：

• 临时开启核心转储（生产环境优先用临时配置，避免影响全局）：
  1. 先查当前限制：ulimit -c，如果输出是0，说明核心转储被关闭了。
  2. 对当前会话临时开启无限制转储：ulimit -c unlimited；如果是systemd管理的进程，需要在服务配置文件里加LimitCORE=infinity，然后执行systemctl daemon-reload && systemctl restart 服务名——这个会重启一次进程，但之后进程崩溃就会自动生成core文件。
• 自定义转储路径和命名：默认core文件会生成在进程的工作目录，可修改/proc/sys/kernel/core_pattern指定路径，比如echo "/var/core/core-%e-%p-%t" > /proc/sys/kernel/core_pattern，这样文件名会包含进程名、PID、崩溃时间，方便识别。记得先创建/var/core目录，并给进程所属用户分配写权限。
• 低侵入式主动抓转储：如果进程还在运行但你预判它会崩溃，可以用gcore <进程PID>命令——这个命令会给进程发信号生成core文件，但不会终止进程，对生产业务的影响几乎可以忽略，适合提前保存现场。

拿到core文件后，就可以拿到测试环境离线分析，完全不用碰生产：

• 关键前提：必须用和生产环境完全匹配的进程二进制文件（哪怕没有调试信息，也要是同一编译版本的可执行文件，否则符号对应不上）。
• 用gdb加载core文件：gdb ./你的进程二进制文件 ./core-xxx
• 即使没有调试信息，也能挖到关键线索：
  • 执行bt查看调用栈：虽然函数名可能是内存地址，但能看到崩溃时的调用层级，比如是在某个系统调用里崩溃的？
  • 执行info registers查看寄存器状态：比如SIGSEGV异常时，能看到哪个寄存器指向了非法内存地址。
  • 执行x/10x $pc查看程序计数器附近的汇编指令，结合上下文猜崩溃原因。
  • 执行info sharedlibrary查看加载的动态库版本，排查是不是依赖库版本不兼容导致的问题。

如果核心转储还不够，还可以用跟踪工具抓系统调用或库函数调用：

• strace跟踪系统调用：strace -p <进程PID> -o strace.log -s 1024，这个会记录进程所有的系统调用（包括参数和返回值），对系统负载有轻微影响，但只要进程不是高并发场景，完全可以接受。等进程崩溃后，看strace.log的最后几行，就能知道它最后在执行什么操作（比如是不是malloc失败，或是访问了不存在的文件）。
• ltrace跟踪库函数调用：如果是动态链接的进程，ltrace -p <进程PID> -o ltrace.log可以跟踪libc或其他依赖库的函数调用，比如是不是重复free了同一个指针？

内容的提问来源于stack exchange，提问作者RKum