答案是：需结合 journalctl 和 coredumpctl 定位崩溃根源，先用 journalctl 找崩溃日志及 PID，再用 coredumpctl 查 core 文件并用 gdb 回溯调用栈，最后交叉验证日志上下文与内核信息。
直接用 journalctl 查 coredump 日志，关键不是“看到 Core dumped”四个字，而是把这条日志当作起点，顺藤摸瓜找到崩溃前后的完整上下文和对应 core 文件。
先确认 systemd 是否捕获了这次崩溃
systemd 默认接管所有进程的 core dump，不会直接写成 core 文件丢在程序目录里。所以第一步是查它有没有记录：
- 运行
journalctl -u your-service-name.service --no-pager -n 50，找含core dumped或segfault的行 - 更精准一点：用
journalctl | grep -E "(core.*dump|segfault|exited.*code 139|signal.*11)" | tail -n 20，快速筛出最近的疑似崩溃事件 - 重点看日志里的
_PID和时间戳，比如：systemd-coredump[1234]: Process 5678 (myapp) of user 1000 dumped core.—— 这里的5678就是崩溃进程 PID，后面分析要用
用 coredumpctl 找并检查 core 文件
只要 journalctl 显示了 systemd-coredump 记录，就说明 core 已被安全存档，不用满硬盘找文件：
- 列出所有已存档的 core：
coredumpctl list，按时间倒序，最新的一条最可能相关 - 按服务名筛选：
coredumpctl list myapp，确认是否存在、大小是否合理（太小可能是截断，太大可能是误报） - 查看详细信息：
coredumpctl info myapp，会显示生成时间、UID、可执行路径、信号类型（如 SIGSEGV）、以及是否带调试符号
用 gdb 加载 core 定位崩溃点
拿到 core 后，真正定位代码问题靠的是 gdb，不是日志本身：
- 直接调试：
coredumpctl debug myapp（自动匹配可执行文件和 core，最省事） - 或手动加载：
gdb /usr/bin/myapp /var/lib/systemd/coredump/core.myapp.1000.…… - 进 gdb 后第一件事：
bt（backtrace），看调用栈顶——那一行就是崩溃发生的源码位置 - 如果
bt显示??或只有地址，说明缺少调试符号：需重新编译加-g，或安装myapp-dbg包
结合日志交叉验证崩溃原因
core 告诉你“哪里崩”，journalctl 告诉你“为什么崩”。两者必须对照看：
- 用崩溃时间点（从 coredumpctl info 中获取）向前查 5 分钟日志：
journalctl --since "2026-06-11 19:30:00" --until "2026-06-11 19:35:00" -o short-precise - 特别留意：
Out of memory、kill process（OOM）、timeout（启动超时）、permission denied（权限失败）等铺垫性错误 - 查内核是否干预：
dmesg -T | grep -A2 -B2 "$(date -d '1 minute ago' '+%b %d')" | grep -i "oom\|segfault\|killed process"
