dmesg中真正的崩溃线索需用dmesg -t | grep -e "(panic|oops|bug|die|warning: cpu)"过滤，并结合/var/log/kern.log或/messages、edac/mce硬件错误日志及时间戳向前追溯。
怎么看 dmesg 里真正的崩溃线索
Linux 崩溃后，dmesg 是第一手现场，但默认输出全是滚动日志，真正致命的错误（比如 Kernel panic、Oops、BUG: unable to handle kernel NULL pointer dereference）往往被刷走或混在大量驱动初始化信息里。
关键不是翻屏，而是过滤和定位：
- 立刻执行
dmesg -T | grep -E "(panic|Oops|BUG|die|WARNING: CPU)"——-T加上本地时间戳，避免时区混淆；grep用正则抓核心关键词，比肉眼扫快得多 - 如果系统还能进，优先看
/var/log/kern.log（Debian/Ubuntu）或/var/log/messages（RHEL/CentOS），这些是 syslog 持久化后的dmesg快照，更稳定 - 注意时间戳对齐：硬件故障（如内存坏块）常伴随
EDAC MC或mce: Hardware error日志，它们可能比 panic 早几秒出现，得往前翻 20–30 行
systemd-journald 崩溃前的日志能捞出来吗
能，但前提是 journal 没被配置成 volatile 模式，且崩溃没直接干掉 journald 进程本身。很多用户以为 journal 日志“全丢了”，其实是没找对位置或权限不对。
实操要点：
- 先确认 journal 是否持久化：
ls /var/log/journal/—— 如果目录为空或根本不存在，说明 journal 默认写在/run/log/journal/（内存临时目录），重启即丢 - 恢复上次启动的完整日志：
journalctl --boot=-1（注意是=-1，不是-1）；如果崩溃后还能进系统，这个命令大概率能拿到崩溃前 5–10 分钟的用户态服务行为（比如postgres卡死、dockerdsegfault） - 权限问题常见：普通用户执行
journalctl可能看不到内核或系统服务日志，加sudo或确保用户在systemd-journal组里
coredump 文件在哪、怎么确认它真生成了
崩溃未必产生 coredump，即使开了，也常因路径、权限、大小限制被静默丢弃。别只查 /var/lib/systemd/coredump/ 就算完。
三步验证：
- 查是否启用：
systemctl status systemd-coredump看是否 active；再看sysctl kernel.core_pattern—— 如果返回|/usr/lib/systemd/systemd-coredump，说明走 systemd 管理；如果是/tmp/core.%e.%p这类路径，说明走传统内核机制 - 查磁盘空间和配额：
systemd-coredump默认限制单个 core 2G、总量 16G，超限就删老文件；用coredumpctl list看有没有记录，空输出 ≠ 没崩溃，可能是被自动清理了 - 手动触发测试：
kill -SEGV $$（对自己 shell 发信号），然后立刻coredumpctl list | head -3，确认流程通不通——这比等真崩溃再排查快得多
硬件故障迹象藏在哪几行 dmesg 里
内存、硬盘、PCIe 设备出问题，Linux 内核会记，但提示非常克制，不像 Windows 那样弹蓝屏代码。重点盯这几类行：
-
EDAC MC0: Giving out device to module skx_edac controller Skylake Socket #0 Channel #0: DEV 0000:ff:05.0—— EDAC 行代表内存校验纠错已触发，后面若跟CE（Correctable Error）还能扛，UE（Uncorrectable Error）就是硬错误，大概率要宕机 -
nvme nvme0: Device not ready; aborting reset或ataX.00: failed command: READ FPDMA QUEUED—— NVMe 或 SATA 盘响应超时，不是线缆松动就是固件/坏道问题，这类错误常在 panic 前反复出现 3–5 次 -
PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)—— PCIe 链路层错误，尤其是severity=Fatal时，基本可锁定主板插槽、显卡或 NVMe 扩展卡接触不良
这些线索不会自己标红加粗，得你主动 grep 和纵向比对时间戳。最麻烦的是多设备交叉影响——比如内存错误导致 NVMe 驱动误判超时，最终 panic 显示的是 disk 错误，但根子在 RAM。这时候不能只盯最后一行。
