journalctl 本身不提供防篡改校验，其“完整性”指日志未损坏、未丢失、结构可读；需通过 journalctl --verify 检测二进制结构，结合 --disk-usage、--stats、权限检查、Storage=persistent 配置及启动记录交叉验证。
journalctl 本身不提供防篡改或密码学校验，它的“完整性”主要指日志文件未损坏、结构可读、内容未意外丢失。检查重点不是验证签名，而是确认日志是否可用、连续、未被截断或权限破坏。
运行 journalctl --verify 检测结构损坏
这是最直接的内置检查方式：
- 执行 journalctl --verify，它会扫描
/var/log/journal/下所有 journal 文件，校验内部对象头、索引一致性、条目长度等二进制结构 - 若输出中出现 FAIL、Invalid object header 或具体文件路径报错，说明该 journal 文件已损坏，无法安全读取
- 成功时仅显示类似 PASS: /var/log/journal/xxx/... ，无错误即表示结构层面基本正常
结合磁盘用量与条目统计交叉验证
单纯 --verify 通过不代表日志逻辑完整，需辅助判断是否异常缺失：
- 运行 journalctl --disk-usage 查看当前占用空间；再运行 journalctl --stats 查看总条目数、最早/最晚时间戳
- 如果磁盘用量明显（如 >100MB），但
Number of entries为 0 或极低（如个位数），大概率是 journal 文件元数据损坏，导致条目不可见 - 如果
Earliest entry时间远早于系统实际部署时间，或Latest entry停滞在几天前，而--disk-usage却有增长，可能说明写入异常或日志轮转配置冲突
确认持久化配置与目录状态
日志“缺失”常因未启用持久化，而非损坏：
- 检查 /etc/systemd/journald.conf 中
Storage=是否设为 persistent（非 volatile 或 auto） - 确认 /var/log/journal/ 目录存在、非空，且属主为
root:systemd-journal，权限为755 - 执行 journalctl --list-boots，观察是否列出多个 boot ID；若只有当前一次（-0），且重启后消失，说明日志仍存于
/run/log/journal/（volatile 模式），未落盘
用启动记录和内核日志反向比对
没有哈希值，但可通过外部事实验证日志是否可信连续：
- 运行 journalctl --list-boots，检查 boot ID 的时间顺序是否连贯；跳变（如从 2026-09-20 突然到 2026-09-23）、重复或缺失某天，提示日志被清理或文件损坏
- 对比 journalctl -k -b（本次启动内核日志）与 dmesg -T 输出首条时间戳；两者应高度一致；若 journalctl -k 为空或条目极少，说明内核日志未成功进入 journald，可能是配置或权限问题
