du -d1 /仅能查看根目录各子目录占用，无法定位应用层死循环日志；需结合lsof查活跃写入大文件、find筛近期超大日志、ps定位异常进程，并通过清空文件+配置轮转+磁盘告警实现根治。
用 du -d1 / 可以快速查看根目录下各一级子目录的磁盘占用，但仅靠它无法直接定位“应用层死循环日志”——这类问题的关键在于：日志文件往往持续追加、增长极快、可能被应用重定向到非标准路径（如 /var/log/myapp/、/opt/app/logs/，甚至 /tmp/ 或当前工作目录），且文件句柄可能被进程持有、即使被轮转或删除，空间也不会立即释放。
先抓“正在疯长”的活跃大文件
死循环日志本质是进程不断写入一个打开的文件。优先检查哪些文件正被高频写入：
- 运行
sudo lsof +L1查看被删除但仍被进程占用的“幽灵大文件”（常见于日志未 reload 导致） - 运行
sudo lsof -nP +D / | awk '$7 ~ /^[0-9]+$/ && $7 > 100000000 {print $7, $9}' | sort -nr | head -10—— 找出当前被打开、且已写入超 100MB 的文件（单位字节），按大小倒序排 - 配合
watch -n 1 'ls -lt /var/log/ /opt/*/logs/ 2>/dev/null | head -5'观察最近修改时间频繁变动的文件
聚焦可疑日志目录并过滤活跃写入进程
不要只扫 /var/log，应用日志常藏在：
-
/opt/app-name/logs/、/home/appuser/logs/、/srv/app/logs/ -
/tmp/下以.log、err、out结尾的文件（尤其注意nohup.out或重定向漏网日志） - 用
find /var/log /opt /home /tmp -name "*.log" -size +50M -mtime -1 2>/dev/null快速筛出近一天内超 50MB 的日志文件
确认罪魁进程并安全止损
找到异常大日志后，立刻查是谁在写它：
- 执行
lsof +D /path/to/suspicious.log或lsof /path/to/suspicious.log，看 PID 和 COMMAND 列 - 用
ps -fp PID看进程启动命令和工作目录，确认是否为预期服务；若为测试脚本、遗留后台任务或配置错误的守护进程，需干预 - 紧急止血：不要直接
rm正在写入的日志；推荐echo "" > /path/to/file.log清空内容（保持 inode 和句柄有效），再查日志配置是否关闭 debug/trace 级别输出
防止复发：从配置和监控入手
单次清理治标，机制建设治本：
- 检查应用日志框架配置（如 log4j2.xml、logback.xml、systemd-journald 的
SystemMaxUse=），禁用无限追加、启用按大小+数量轮转 - 对关键日志目录添加
logrotate配置（即使应用自轮转，也建议双保险） - 部署基础磁盘告警：用
df -h / | awk 'NR==2 {if($5+0 > 85) print "ALERT: / usage "$5}'加入定时检查，或接入 Prometheus + node_exporter
