应使用journalctl -b -1 -p err..emerg查上次启动日志，因假死时日志写入常中断；需先启用持久化存储（storage=persistent）并验证journalctl --list-boots含多条记录。
直接用 journalctl -u -p crit 并不能监控“系统假死”——因为假死（如内核卡死、无响应、黑屏、SSH断连）往往意味着日志写入已中断，critical 级别日志本身可能根本没来得及生成或落盘。真正有效的做法是组合使用 -b、-k、-p 和 --since，并确保日志持久化启用。
下面分三步说清楚怎么查、为什么这么查、以及容易忽略的关键点：
查看本次启动中内核与关键服务的严重级别日志
系统假死常源于内核 panic、驱动崩溃、硬件异常或 systemd 本身故障。这类事件多数会触发 crit 或更高级别（err/alert/emerg）日志，但必须限定在当前启动上下文中查看，否则会被历史日志淹没。
-
查看本次启动中所有
crit及以上级别日志（含内核 + 所有服务）：journalctl -b -p crit..emerg
这里
-p crit..emerg表示优先级从crit（2）到emerg（0）的全部严重日志，比单用-p crit更全面。 -
单独聚焦内核崩溃线索（比服务日志更底层）：
journalctl -b -k -p err..emerg
-k只显示内核日志，-p err..emerg过滤出错误及以上，能快速定位 oops、panic、NMI watchdog timeout、hard lockup 等典型假死前兆。
回溯崩溃前最后活跃时段的日志
假死发生时系统可能已停止写日志，所以要重点看“停摆前最后一段还在输出的时间窗口”，而不是等它“报错”。
-
查看最近 15 分钟内所有
err级别以上的服务日志（尤其关注systemd,kernel,journald,dbus）：journalctl --since "15 minutes ago" -p err..emerg | grep -E "(systemd|kernel|journald|dbus|oom)"
-
若已重启，立即查上一次启动日志（这是诊断假死的核心）：
journalctl -b -1 -p err..emerg --no-pager | tail -n 100
-b -1是关键——它读取的是上次启动的完整日志缓冲区，哪怕那次启动最终卡死了，只要 journald 在崩溃前还活着，这部分日志就还在内存或磁盘里。
确保你能查到这些日志（前提条件）
很多用户查不到 -b -1 日志，不是命令不对，而是系统根本没存住：
-
检查是否启用日志持久化：
ls /var/log/journal/
若提示
No such file or directory，说明日志只存在内存（volatile），重启即清空。需手动启用：sudo mkdir -p /var/log/journal sudo chown root:root /var/log/journal echo "Storage=persistent" | sudo tee -a /etc/systemd/journald.conf sudo systemctl kill --signal=SIGUSR1 systemd-journald
-
验证是否生效：
journalctl --list-boots
正常应显示多条启动记录（如
-1,-2,0），而非只有0。
不复杂但容易忽略。
