《磁盘空间突然没了，df 一看却还有：journal 日志把根分区吃满了》

昨天一台机器突然报警，根分区用了 95%，再写文件就报错。但 du -sh /* 一路加下来，大头都对不上号，少了好几个 G。最后查到是 systemd 的 journal 日志在悄悄吃空间。

第一处：先看 journal 占了多少

journalctl --disk-usage

这条直接告诉你日志占了多少磁盘。一台跑了几个月的机器，journal 吃掉几个 G 很常见，尤其是某个服务一直在刷 error 日志的时候。

第二处：清理加限流，两步做

清理只留最近 200M：

journalctl --vacuum-size=200M

想彻底一点，也可以按时间清：

journalctl --vacuum-time=7d

清完还得限流，不然过几天又满。改 /etc/systemd/journald.conf：

SystemMaxUse=200M
MaxFileSec=7day

然后重启 journald 生效：

systemctl restart systemd-journald

注意：vacuum 删的是已归档的日志，正在写的当前日志文件不动，服务不用停。

第三处：再查 /var/log 里失控的单个日志

journal 清完了如果空间还是不对，换 du 定位：

du -sh /var/log/* | sort -rh | head

经常是某个应用的日志文件一个月没轮转，单个文件就几 G。临时处理直接清空，不要 rm，进程还占着句柄，rm 了空间也不释放：

: > /var/log/xxx.log

长久之计是确认 logrotate 在跑：看 /etc/logrotate.d/ 里有没有这个应用的配置，没有就补一条，按天轮转、保留 7 份。

最后：如果 du 和 df 还是对不上

du 算的是文件实际大小，df 看的是文件系统已用块。两者差得多，先看有没有被删掉但还被进程占着的文件：

lsof | grep deleted

有就重启对应进程；没有就看挂载点：某个目录被单独挂载后，旧文件还留在根分区原位置，du 走挂载路径看不到。

三板斧记好：journalctl --disk-usage、du -sh /var/log/*、lsof | grep deleted。磁盘满了先别急着扩容，大概率是日志在作怪。