查服务崩溃原因需先用journalctl定位崩溃时间与PID，再通过coredumpctl和gdb分析core文件确定代码行，最后结合前后日志与dmesg确认诱因。
查服务崩溃原因，关键不是只看“Core dumped”四个字，而是用 journalctl 找到崩溃时间点和 PID，再结合 coredumpctl 和 gdb 定位具体代码位置，最后回看日志上下文确认诱因。
先用 journalctl 锁定崩溃时间和进程 ID
systemd 默认接管 core dump，不会把 core 文件直接写进程序目录。所以第一步是确认它是否记录了这次崩溃：
- 查服务最近日志：journalctl -u your-service.service --no-pager -n 50，找含 core dumped、segfault 或 exited with code 139 的行
- 快速筛出所有疑似崩溃：journalctl | grep -E "(core.*dump|segfault|signal.*11)" | tail -n 20
- 重点提取日志里的 PID —— 比如这行：systemd-coredump[1234]: Process 5678 (myapp) of user 1000 dumped core.，其中 5678 就是崩溃时的进程号，后面调试要用
再用 coredumpctl 查看已存档的 core 文件
只要 journalctl 显示了 systemd-coredump 记录，说明 core 已被安全归档，不用手动满盘搜索：
- 列出全部已存档 core：coredumpctl list（默认按时间倒序，最新一条最相关）
- 按服务名筛选：coredumpctl list myapp，确认是否存在、大小是否合理（太小可能是截断，太大可能是误报）
- 查看详细信息：coredumpctl info myapp，会显示生成时间、UID、可执行路径、信号类型（如 SIGSEGV），以及是否带调试符号
用 gdb 回溯调用栈，定位崩溃源码行
core 告诉你“哪里崩”，gdb 才能告诉你“哪一行崩”：
- 最省事方式：coredumpctl debug myapp（自动匹配可执行文件和 core）
- 手动加载：gdb /usr/bin/myapp /var/lib/systemd/coredump/core.myapp.1000.……
- 进 gdb 后第一件事：bt（backtrace），看调用栈顶那一行——就是崩溃发生的源码位置
- 如果 bt 显示 ?? 或只有地址，说明缺少调试符号：需重新编译加 -g，或安装 myapp-dbg 包
交叉验证日志上下文，找出真正诱因
崩溃点只是结果，日志里藏着原因。必须把时间点对齐，往前查：
- 用 coredumpctl info 中的时间（比如 2026-10-12 13:45:22），向前查 5 分钟日志：journalctl --since "2026-10-12 13:40:00" --until "2026-10-12 13:45:00" -o short-precise
- 重点关注：Out of memory、kill process (OOM)、timeout、permission denied、disk full 等铺垫性错误
- 查内核是否干预：dmesg -T | grep -A2 -B2 "Oct 12 13:45"（用相近时间戳搜），看有没有 OOM killer、硬件错误等底层痕迹
