journalctl日志“丢失”主因是默认仅存内存且未启用持久化，需确认storage=persistent配置、检查disk-usage配额、验证standardoutput/standarderror是否重定向至journal。
journalctl 日志“丢失”，通常不是日志被删了，而是根本没存下来——默认配置下它只驻留内存，重启即清空。排查核心就三件事：确认日志是否落盘、查当前存储配额、验证服务是否真在记录。
确认 journal 是否启用持久化
默认 journalctl 只读 /run/log/journal/ 下的内存日志，系统重启后全部消失。执行以下命令判断：
-
查存储位置与用量：
journalctl --disk-usage—— 若显示0B，说明未启用持久化 -
看当前配置：
cat /etc/systemd/journald.conf | grep -E "^(Storage|SystemMaxUse)"—— 若Storage=volatile或该行被注释，就是问题根源 -
启用落盘：创建
/etc/systemd/journald.conf.d/persistent.conf，写入： [Journal]
Storage=persistent
SystemMaxUse=512M
MaxRetentionSec=3month -
生效配置：运行
sudo systemctl kill --signal=SIGUSR1 --kill-who=main systemd-journald（无需 restart）
检查日志是否被轮转或截断
即使启用了持久化，日志也可能因空间限制被自动清理：
- 用
journalctl --disk-usage查当前占用；若接近SystemMaxUse值，旧日志已被删 - 查最近保留策略：
journalctl --list-boots—— 若只显示本次启动（-0），说明历史 boot 日志已不可见 - 临时扩大容量：改
SystemMaxUse=1G后再发SIGUSR1重载，避免重启服务
验证服务日志是否真的被采集
有些服务看似在跑，但日志根本没进 journald：
- 先查服务 unit 文件：
systemctl cat your-service.service，确认含StandardOutput=journal和StandardError=journal - 若缺失，手动加这两行并执行
sudo systemctl daemon-reload && sudo systemctl restart your-service - 绕过 unit 直接按进程查：
journalctl _COMM=your-binary-name（比如_COMM=nginx），比-u更底层，能捕获非 systemd 启动的实例 - 检查进程 stdout/stderr：
ls -l /proc/$(pgrep -f your-binary)/fd/{1,2}—— 若指向/dev/null或权限不足路径，日志就静默丢失了
用结构化方式查，别靠 grep 硬扫
直接 journalctl | grep xxx 容易漏，因为时间戳、优先级前缀干扰匹配：
- 用 JSON 输出 + jq 过滤：
journalctl -u your-service -o json | jq 'select(.MESSAGE | contains("timeout"))' - 限定时间范围更可靠：
journalctl -u your-service --since "2026-09-15 10:00:00"，比--since "2 hours ago"少受时钟跳变影响 - 查启动瞬间错误：
journalctl -b -u your-service --no-pager | head -n 50，很多崩溃只在 fork 后第一秒输出
