已删除但未释放的日志文件会占用磁盘空间，可用lsof +L1定位，通过kill -HUP重载日志或echo > /proc/PID/fd/N清空来释放空间，并建议结合logrotate和监控预防。
当一个日志文件被进程打开后又被 rm 删除，该文件的 inode 仍被进程持有，磁盘空间不会立即释放。此时用 df 看磁盘已满，但 du 却统计不到对应大小——这正是“已删除但未释放”的典型场景。lsof 是定位这类文件最直接的工具。
识别被占用的已删除文件
运行以下命令，筛选出当前系统中所有状态为 (deleted) 的打开文件：
lsof +L1
该命令专用于列出链接计数（link count）为 0 的打开文件，即已被删除但仍被进程持有的文件。输出示例：
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
rsyslogd 1234 root 1w REG 253,0 12345678 123456 /var/log/syslog (deleted)
重点关注 NAME 列中标有 (deleted) 的行，以及 PID 和 COMMAND 列，确认是哪个进程占用了哪个已删日志。
确认文件实际占用空间
仅靠 lsof +L1 可知存在，但需确认它是否真正在撑满磁盘。可结合 ls -l /proc/PID/fd/FD号 查看具体大小：
ls -lh /proc/1234/fd/1
若显示类似 /var/log/syslog (deleted) -> /dev/null 或真实大小（如 1.2G），说明该句柄确实在持续写入并占用空间。
也可用 du -sh /proc/1234/fd/1 直接查看该文件描述符指向内容的磁盘用量。
安全释放空间的两种方式
释放空间不等于杀进程，优先选择对业务影响最小的方式：
-
向进程发送日志重载信号：多数日志服务（如 rsyslog、nginx、java 应用等）支持
SIGHUP重开日志文件。执行：kill -HUP 1234。进程会关闭旧 fd、重新打开新日志文件，原已删文件的引用自动释放，空间立即回收。 -
清空文件描述符内容（慎用）：若无法重载且必须立刻释放，可直接截断该 fd 对应的文件内容：
echo > /proc/1234/fd/1。
⚠️ 注意：这会清空当前正在写入的缓冲内容，部分应用可能报错或丢日志，仅建议在紧急排障且确认无影响时使用。
预防与排查习惯建议
避免反复陷入此类问题：
- 定期用
lsof +L1 | grep log检查日志类 deleted 文件； - 日志轮转（logrotate）配置中务必包含
copytruncate或显式调用kill -USR1/-HUP，确保进程及时切换文件； - 监控脚本中不要只依赖
du，应同时检查df与lsof +L1输出差异； - 对 Java 应用等自管理日志的程序，确认其日志框架（Log4j/Logback）是否配置了正确的
RollingFileAppender和触发策略。
