最常见原因是已删除但被进程占用的文件：执行lsof +l1可查到如java 12345 appuser 123w reg 8,1 20g /var/log/app/app.log (deleted)，此时需重启进程或发送信号释放句柄。
文件系统日志空间填满本身不是标准 Linux 概念——/var/log 是普通目录，不自带“日志空间配额”；所谓“日志填满”，本质是 / 或 /var 所在的文件系统被大量日志文件占满。排查的关键不是查“日志空间记录”，而是定位哪些日志文件膨胀、是否被进程持续写入、删了为何不释放空间。
df -h 显示 100% 但 du 统计不到对应大小？看 lsof 找被删除却仍被占用的文件
这是最常被忽略的坑：文件被 rm 删除，但仍有进程打开着它的 fd，磁盘空间不会释放。此时 df 显示已满，du 却找不到大文件。
- 运行
lsof +L1—— 列出所有链接数为 0（即已被删除但句柄未关闭）的文件 - 重点关注
COMMAND列为java、nginx、rsyslogd等长期运行服务的条目 - 若看到类似
/var/log/tomcat/catalina.out (deleted)，说明该文件虽删了，但进程还在往它写 - 解决方法：重启对应服务（如
systemctl restart tomcat），或kill -HUP触发日志 reopen（需服务支持）
du -sh /var/log/* | sort -hr 快速识别膨胀的日志目录
/var/log 是日志主战场，但不同服务存放位置不一，直接按目录汇总比逐个 ls -lh 高效得多。
-
du -sh /var/log/* 2>/dev/null | sort -hr—— 排除权限错误，按大小倒序列出子目录 - 常见大户：
journald（/var/log/journal）、docker（/var/lib/docker/containers/*/logs）、tomcat（/opt/tomcat/logs）、nginx（/var/log/nginx） - 注意：
journalctl --disk-usage可单独查 systemd-journal 占用，有时达数 GB - 若发现
/var/log/audit异常大，检查 SELinux 审计是否开启且未轮转
find /var/log -name "*.log" -mtime +30 -delete 清理旧日志前先确认轮转机制
盲目 rm 可能导致服务报错或日志丢失；优先检查 logrotate 是否生效。
- 查配置：
ls /etc/logrotate.d/，看是否有对应服务（如nginx、tomcat）的规则 - 手动测试轮转：
logrotate -d /etc/logrotate.d/nginx（-d表示 debug 模式，不真删） - 若无轮转或失效，再执行清理：
find /var/log -name "*.log" -type f -mtime +30 -size +1M -delete - ⚠️ 避免用
rm -f *.log：当前正在写的catalina.out被删后，Java 进程会继续往原 inode 写，新文件名不可见且无法控制大小
journalctl --vacuum-size=100M 清理 systemd-journal 日志
systemd-journal 默认不限制大小，/var/log/journal/ 常 silently 吃掉几十 GB 空间。
- 先看现状：
journalctl --disk-usage - 限制总大小：
journalctl --vacuum-size=100M（立即释放超限部分） - 永久生效：编辑
/etc/systemd/journald.conf，取消注释并修改SystemMaxUse=100M，然后systemctl kill --signal=SIGUSR1 systemd-journald - 注意：
--vacuum-size不影响当前 session 的内存 journal，只清理磁盘持久化部分
真正卡住人的从来不是“怎么删日志”，而是删完空间不释放、轮转没生效、或误删正在被进程持有的文件。每次清理前，先 lsof +L1 和 journalctl --disk-usage 过一遍，能避开 80% 的诡异问题。
