需结合 journalctl、coredumpctl 和 gdb 定位崩溃根源：先用 journalctl 找崩溃日志及 PID，再用 coredumpctl 查 core 文件并用 gdb 回溯调用栈，最后交叉验证日志上下文与内核信息。
要通过 journalctl 关联查看应用 crash 的核心内存转储（coredump）日志，关键不是单独翻日志，而是把 journalctl 当作“线索索引器”，再用 coredumpctl 和 gdb 把线索变成定位依据。
从 journalctl 找到崩溃的起点
systemd 默认捕获所有崩溃并记录到 journal，但不会把 core 文件丢在程序目录里。先确认它有没有记下这次 crash：
- 查指定服务最近的崩溃痕迹：journalctl -u your-app.service --no-pager -n 50 | grep -i "core.*dump\|segfault\|signal.*11"
- 更宽泛地筛全系统近期异常：journalctl | grep -E "(exited.*code 139|SIGSEGV|dumped core)" | tail -n 15
- 重点提取日志里的 PID 和时间戳，例如：systemd-coredump[890]: Process 12345 (your-app) of user 1000 dumped core. —— 这里的 12345 就是后续分析要用的进程 ID
用 coredumpctl 匹配并确认 core 文件存在
只要 journal 里出现 systemd-coredump 记录，说明 core 已被安全归档，路径统一在 /var/lib/systemd/coredump/ 下，不用手动搜。
- 列出所有已存档的 core：coredumpctl list（默认按时间倒序，最新一条最相关）
- 按应用名筛选确认：coredumpctl list your-app（看是否有条目、大小是否合理，几十 KB 以下可能截断，几百 MB 以上需留意是否误报）
- 查看详细信息定位信号和可执行路径：coredumpctl info your-app，重点关注：Signal（如 SIGSEGV）、Executable（实际二进制路径）、Storage（core 是否带调试符号）
用 gdb 回溯崩溃点，结合日志上下文验证
core 告诉你“哪一行崩了”，journal 告诉你“为什么崩”。两者必须对照着看。
- 一键调试（推荐）：coredumpctl debug your-app（自动匹配 binary + core，进 gdb 后直接输入 bt 查调用栈）
- 手动加载（需路径明确）：gdb /usr/bin/your-app /var/lib/systemd/coredump/core.your-app.1000.……
- 若 bt 显示 ?? 或地址，说明缺调试符号：需重装带 -g 编译的版本，或安装 your-app-dbg 包
- 回到 journal，用 coredumpctl info 中的时间点，向前查 3–5 分钟日志：journalctl --since "2026-07-06 14:22:00" --until "2026-07-06 14:27:00" -o short-precise，特别留意：Out of memory、permission denied、timeout、failed to allocate 等铺垫性错误
补充验证：检查内核是否干预或资源见底
有些 crash 表面是应用 segfault，实则是内核 OOM killer 杀掉的，或硬件温度触发保护。
- 查 OOM 记录：journalctl -k | grep -i "out of memory"
- 查内核级硬件警告：journalctl -k --since "1 hour ago" | grep -i "temperature\|error\|fail"
- 对比 dmesg 最后几行：dmesg -T | tail -n 30，有时 kernel ring buffer 比 journal 更早留下痕迹
