核心转储抓现场
进程毫无征兆地退出时，最重要的证据就是核心转储：它记录了崩溃瞬间的内存镜像与调用栈。默认不少发行版把核心转储关掉了（资源限制为 0），因此第一步是确认开关与落盘路径，第二步才是取出现场看栈。比起反复复现，直接分析一次核心转储要快得多。
基本信息
| 典型场景 | 服务莫名其妙退出、段错误、被信号杀死需要根因 |
|---|---|
| 组合手段 | ulimit -c 检查开关 + core_pattern 定位落盘方式 + coredumpctl 或 gdb 分析 |
| 适用范围 | Linux；systemd 发行版一般由 systemd-coredump 统一托管 |
| 前置条件 | 需要复现用的可执行文件与调试符号，栈信息才完整 |
典型使用场景
- 服务重启后日志只留下 killed 一行，需要找出杀掉它的原因
- C 或 C++ 程序偶发段错误，抓现场比加日志重跑更省时间
- 确认是应用自身 bug 还是被系统的 OOM 机制终止
- 核对崩溃进程当时加载了哪些动态库版本
- 给开发同学提供可离线分析的完整现场文件
检查与开启
检查与开启
ulimit -c # 0 表示当前会话不产出 core
cat /proc/sys/kernel/core_pattern # 看落盘路径或是否交给外部程序托管
ulimit -c unlimited # 仅对当前会话生效
sudo systemctl edit myservice # 服务方式：在单元里加 LimitCORE=infinity
cat /etc/systemd/coredump.conf # systemd 托管时的存储与大小上限
journalctl -k | grep -i 'segfault\|oom' # 内核侧也会留下线索查看现场
查看现场
coredumpctl list | tail # 最近的转储记录
coredumpctl info myservice # 退出信号、命令行、栈摘要
coredumpctl debug myservice # 直接进入调试器
bt # 在调试器里打印调用栈
coredumpctl dump myservice --output=/tmp/core.myservice # 导出文件留档检查项读法
| 检查项 | 常见值 | 含义 |
|---|---|---|
| ulimit -c | 0 | 完全不产出核心转储，最常见的原因 |
| core_pattern 为 core | 相对路径 | 写进程当前工作目录，可能散落多处 |
| core_pattern 以竖线开头 | 交给外部程序处理 | 通常指向 systemd-coredump，改用 coredumpctl 查看 |
| /var/lib/systemd/coredump | 目录存在即有转储 | systemd 托管的默认落盘位置 |
| Storage= | external / journal / none | none 表示丢弃，需改为保留 |
核心转储可能包含口令、密钥等敏感内存数据，文件权限、保存时长与清理策略要一并纳入安全流程，别随手拷来拷去。