登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  文章 >  linux

journald 怎么把重启前的日志持久化到磁盘

来源:17golang原创

时间:2026-10-05 14:53:39 166浏览 收藏

要保留重启前的 journald 日志,最直接的做法是把 Storage= 设为 persistent。这样日志优先写入 /var/log/journal;早期启动阶段或磁盘暂时不可写时,journald 仍可能先使用 /run/log/journal,随后由刷新动作迁移到持久目录。

官方手册:https://www.freedesktop.org/software/systemd/man/latest/journald.conf.html

先看基线:为什么重启后只剩当前日志

我排查这类问题时,先不急着改配置,而是记录三个指标:持久目录是否存在、journal 文件占用多少磁盘、当前能识别多少次启动。默认 Storage=auto 时,只有存在 /var/log/journal 才会表现得像持久模式;否则日志通常落在易失的 /run/log/journal,重启后自然消失。

# 查看持久与运行时目录,目录不存在也不要中断后续检查
sudo ls -ld /var/log/journal /run/log/journal 2>/dev/null || true

# 查看当前 journal 文件总占用
journalctl --disk-usage

# 列出当前可查询的启动记录;只有一行通常表示没有旧启动日志
journalctl --list-boots
journald 易失存储与持久磁盘存储关系示意图
运行时日志位于 /run/log/journal,持久日志位于 /var/log/journal;重启后能否查询旧日志取决于磁盘副本。

改动点:用配置片段启用 persistent

官方手册更推荐用 /etc/systemd/journald.conf.d/ 下的 drop-in 覆盖,而不是直接修改发行版主配置。这样升级软件包时更容易保留本机策略,也能通过文件名明确配置优先级。

# 创建管理员配置目录
sudo install -d -m 0755 /etc/systemd/journald.conf.d

# 写入本机持久化策略;单引号 heredoc 防止 shell 展开内容
sudo tee /etc/systemd/journald.conf.d/60-persistent.conf >/dev/null 

Storage=persistent 会在需要时创建持久目录;如果磁盘尚不可写,则仍会临时回退到运行时目录。相比仅手工创建目录,显式配置更清楚地表达了运维意图。

让配置生效并迁移当前日志

完成配置后重启 journald,再调用 journalctl --flush。官方说明中,flush 会在启用持久存储时把 /run/log/journal 中的数据刷新到 /var/log/journal,而且这个动作是幂等的。

# 重启服务,让新的 Storage 策略生效
sudo systemctl restart systemd-journald

# 把本次启动早期写在 /run 中的记录刷新到持久目录
sudo journalctl --flush

# 确认服务状态与持久目录;不输出全部日志以免干扰判断
systemctl is-active systemd-journald
sudo ls -ld /var/log/journal
journalctl --disk-usage

部分系统在启动时由 systemd-journal-flush.service 自动完成刷新,但手动执行一次能让当前改动立即具备明确的验收点。

验收:必须跨一次重启再判断

仅看到 /var/log/journal 目录还不算完成。安排一次可控重启,回来后检查启动列表和上一次启动日志:

# 重启前写入一条容易识别的测试记录
logger -t journald-persistence-test "before-reboot-marker"

# 在维护窗口内执行重启;远程机器先确认有回连与救援手段
sudo systemctl reboot

系统回来后执行:

# 应看到当前启动 0 和至少一个更早的负数启动编号
journalctl --list-boots

# 读取上一次启动的测试标记;-b -1 表示前一次启动
journalctl -b -1 -t journald-persistence-test

# 若要快速看上次启动末尾的系统日志,可限制为最后 50 行
journalctl -b -1 -n 50 --no-pager

判断标准很简单:--list-boots 中出现多个启动,且 -b -1 能读到重启前记录,才说明目标真正达成。

结果边界:持久化以后要限制磁盘占用

日志从内存转到磁盘后,故障追溯能力提高,但磁盘预算也成为长期指标。可以在同一个 drop-in 中加入容量与保留期限制:

[Journal]
# 启用磁盘持久化
Storage=persistent
# journal 最多使用 1 GiB,实际还会受预留空间约束
SystemMaxUse=1G
# 至少给其他数据留下 2 GiB 空间
SystemKeepFree=2G
# 最长保留 30 天;按组织审计与容量要求调整
MaxRetentionSec=30day

SystemMaxUse 和 SystemKeepFree 会同时生效,journald 采用更严格的限制。修改后再次重启 journald 即可。不要照抄容量数字:小型云主机、数据库服务器和日志密集型网关的磁盘预算完全不同。

journald 持久日志容量与保留边界示意图
持久化解决跨重启追溯,SystemMaxUse、SystemKeepFree 和保留期共同约束磁盘风险。

不生效时怎么排查

现象优先检查处理方向
仍没有 /var/log/journal/var 是否已挂载且可写修复只读文件系统、挂载或磁盘空间问题
配置看似被忽略drop-in 文件名和配置优先级检查其他更靠后的配置片段是否覆盖
目录存在但没有旧启动是否执行 flush、是否真的跨过一次重启执行 journalctl --flush 后再做可控重启
日志很快被删除容量与保留策略、磁盘剩余空间调整 SystemMaxUse、SystemKeepFree、MaxRetentionSec
普通用户看不到系统日志权限和用户组用 sudo 验证,再按发行版策略配置读取权限

还可以读取 journald 自身的本次启动日志,定位目录、权限或文件系统错误:

# 只看 journald 服务在本次启动中的告警及以上信息
sudo journalctl -b -u systemd-journald -p warning --no-pager

# 查看所有生效配置来源,发现是否有更高优先级的覆盖项
systemd-analyze cat-config systemd/journald.conf

简要结论

完整动作链是:设置 Storage=persistent、重启 journald、执行 journalctl --flush、可控重启后用 journalctl -b -1 验收。最后再为磁盘用量和保留期设置边界。只创建目录而不做跨重启验证,很容易把“看起来已配置”误当成“确实能恢复旧日志”。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>