日志服务空间爆满是linux磁盘报警最常见原因，排查关键在于确认日志是否持续写入、轮转是否失效、是否被进程锁住；需依次执行df -h和df -i定位挂载点与inode问题，用du和find聚焦大日志文件，通过lsof +l1识别已删未释放的“幽灵日志”，最后用truncate清空或重启服务释放空间，并配置logrotate与journald限制预防复发。
日志服务空间爆满是 Linux 磁盘报警最常见原因，排查关键不是“找大文件”，而是“确认日志是否在持续写入、是否轮转失效、是否被进程锁住”。下面分四步直击核心。
确认是不是日志导致的爆满
先执行两条命令：
-
df -h：看根分区或
/var/log所在挂载点（如/var单独分区）是否 Use% ≥ 90% -
df -i：如果空间还有余量但报
No space left on device，大概率是日志目录下小文件过多耗尽 inode
若 /var/log 对应的挂载点使用率异常高，基本可锁定日志问题。注意别只盯 /，有些系统把 /var/log 单独挂载在 /dev/sdb1 上，根分区看着正常，实际日志已把 /var 塞爆。
快速定位日志目录和活跃大文件
进入高占用挂载点（比如 /var），运行：
-
du -sh */logs 2>/dev/null | sort -hr | head -5：找应用自建日志目录（如
/opt/app/logs） -
du -sh log/* 2>/dev/null | sort -hr | head -5：聚焦
/var/log下子目录（journal、nginx、mysql等） - find /var/log -type f -size +100M -exec ls -lh {} \;：直接列出超 100MB 的日志文件
重点关注：catalina.out、messages、secure、journal、app.log 这类长期不轮转的文件。若发现某个 .out 文件大小每天涨 2GB 且 ls -l 显示时间戳持续更新，说明它正被追加写入且没关闭句柄。
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
检查日志是否被进程占用或已删未释
很多情况下，你 rm -f catalina.out 后 df 不变，就是因为 Java 进程还握着这个文件句柄：
-
lsof +L1：列出所有已删除但仍在被进程打开的文件，输出中带
(deleted)的就是“幽灵日志” - lsof -p $(pgrep -f "java.*tomcat") | grep log：确认具体哪个 Java 进程正在写哪个日志路径
- journalctl --disk-usage：若用 systemd-journald，查日志本身占多少空间（常达数 GB）
看到 (deleted) 文件 SIZE 列显示 8G，就说明删了但空间没还——此时重启对应服务（如 systemctl restart tomcat 或 kill -HUP <pid></pid>）才能真正释放。
安全清理与后续预防
清理前先备份当前状态：df -h > /tmp/df_before_$(date +%s).log。
- 对正在写入的大日志，优先用 truncate -s 0 /var/log/app.log 清空内容，不破坏文件句柄，服务无需重启
- 对已停用或确认无用的日志，用 find /var/log -name "*.log.*" -mtime +30 -delete 批量清理旧归档
- 配置
logrotate：编辑/etc/logrotate.d/myapp，加入daily、rotate 30、compress、missingok和postrotate kill -HUP `cat /var/run/myapp.pid` - 限制 journald：修改
/etc/systemd/journald.conf，设SystemMaxUse=500M，然后systemctl restart systemd-journald
不复杂但容易忽略：Java 应用里 logback-spring.xml 若没配 <timebasedfilenamingandtriggeringpolicy></timebasedfilenamingandtriggeringpolicy>，catalina.out 就永远不会滚动，早晚撑爆磁盘。
