journalctl -p crit 用于筛选临界（crit，级别2）及更严重日志，如 crit、alert、emerg，涵盖磁盘耗尽、服务崩溃、内核 panic 等，可快速定位攻击链后半段高危线索，但需结合 -b、-u、时间范围及关键词（如 avc: denied、oom）交叉分析，并确保日志已持久化存储。
journalctl -p crit 是一个精准定位系统级严重问题的实用命令，但它本身不直接“排查安全漏洞利用”，而是帮你快速捕获可能与漏洞利用相关的高危线索。关键在于理解 -p crit 的作用边界，并配合上下文分析。
明确 -p crit 能做什么-p crit（或等价写法 -p 2）只显示优先级为 crit（critical，级别2）及更严重的日志条目，包括：
-
crit（临界状态，如磁盘空间即将耗尽、服务关键依赖不可用） -
alert（需立即行动，如 root 密码被暴力破解多次） -
emerg（系统不可用，如内核 panic、OOM killer 杀死关键进程）
这类日志往往出现在攻击链后半段——比如提权成功后触发 SELinux 拒绝、容器逃逸导致 systemd 单元崩溃、或恶意进程被内核 cgroup 机制强制终止。
如何用它辅助识别可疑安全行为
不要孤立看 -p crit 输出，要结合时间、服务单元和关键词交叉验证：
查看最近一次启动中的严重错误（排除历史残留干扰）：
journalctl -b -p crit --no-pager
关注是否在登录、服务启动、网络连接建立后立刻出现crit级别报错。锁定与认证、权限、内核强相关的单元：
journalctl -u systemd-logind.service -p critjournalctl -u auditd.service -p critjournalctl -u kernel.service -p crit（注意：内核日志实际对应_kernel单元，可用journalctl -k -p crit更直接）配合关键词过滤缩小范围（例如常见漏洞利用痕迹）：
journalctl -p crit | grep -i "segfault\|oom\|refused\|denied\|capability.*invalid"
出现capability bounding set dropped或avc: denied（SELinux）且紧随用户登录后，值得深度检查。
注意两个易忽略但关键的细节
- 默认 journal 日志不持久化：重启后
/run/log/journal/下内容丢失。若攻击发生在上次重启前，必须已启用持久存储（sudo mkdir -p /var/log/journal && sudo systemctl restart systemd-journald）。 -
crit级别日志是结果，不是原因：它告诉你“系统某处崩了”，但不说明为什么崩。必须回溯该时间点前后 30 秒内的完整日志（journalctl --since "2026-05-08 19:20:00" --until "2026-05-08 19:20:30" --no-pager），观察是否有异常进程启动、非预期的execve调用或大量failed to load报错。
不复杂但容易忽略。
