日志删了 df 还是 100%，进程不重启空间是不是就一直回不来？

先说结论：空间没回来，多数是文件还被进程握着

磁盘告警后删掉日志、df 却不见已用空间下降，常见原因不是删错目录，而是还有进程持有该文件的句柄，lsof 里会显示 deleted。目录项没了，inode 和数据块还在，要等持有它的进程关闭文件或重启才释放。按 2026 年常见交付习惯，先用 lsof +L1 或 /proc 下对应进程的 fd 目录找持有者，再用 df 与 du 的差值判断是「被删未释放」，还是占用根本不在这个目录。df 统计文件系统已分配的块，du 统计还能看到名字的文件，两者对不上不一定是系统坏了。

• 删了没释放：说明有进程在写这个日志，日志框架没重开文件。
• 删完立刻释放：说明没有进程持有，占用在别处，得继续往下找。
• df -h 有空间但写文件报 No space left on device：先去 df -i 看 inode，与块空间无关。

删了还被占，常见是三类引用没断

在 Linux 和多数类 Unix 系统里，删除只是把文件名从目录上摘掉。只要还有进程打开着这个文件，内核就保留 inode 和数据块，直到最后一个句柄关闭。日志场景尤其常见：应用启动时打开 app.log，之后一直追加，你 rm 掉的只是它的名字。

• 进程句柄：应用本身、日志采集 agent、长期挂着的 tail -f 终端都可能持有；重启采集器同样能释放。
• 挂载覆盖：往挂载点里写数据后原目录文件被盖住，du 看不到，空间确实被占；处理时先 umount 再核对。
• 容器可写层：日志写进容器可写层或 overlay 上层，宿主机看到的是镜像层视角，删容器内文件未必释放宿主空间。
• 其他占用大户：数据库 binlog、备份包、core dump、包管理器缓存，常见区间从几百 MB 到数 GB。

定位顺序：先量块、再看 inode、再找句柄

按这个顺序排，是因为信息成本递增：df 一秒出结果，lsof 要权限且在大机器上扫得慢，重启进程有业务代价。先做低成本判断，能少一次半夜重启。

1. 量块：df -h 看各挂载点使用率，先锁定是哪个分区满。
2. 看 inode：df -i 看 inode 使用率，小文件多时会话文件、缩略图、邮件队列常先把 inode 用满。
3. 找句柄：lsof +L1，或在 /proc 下各进程 fd 目录里找带 deleted 的项，记下进程名与文件大小。
4. 确认释放：支持日志重开信号的应用先发信号（具体按应用官方文档核对），不支持的再安排低峰重启，重开后用 df 复核。

第三步常被跳过。交付现场见过运维删完文件看空间没降，又顺手删了归档目录，结果真正占空间的是还开着的 8GB 句柄，白删一轮还丢了历史日志。做到删之前先 lsof、删之后 df 复核一次，就算合格，不必每次都写脚本。

一段交付现场经验：某后台项目日志直接写本地目录，同时有采集 agent 长期开着句柄，磁盘到 90% 告警后运维先 rm 当天日志，df 没降，又删了归档目录。约束是不能直接重启应用（有定时任务在跑）；做法是先 lsof +L1 锁定持有句柄的进程，对应用发重开信号、对采集 agent 走平台重启，再用 truncate 把仍在写的文件清零；结果是已用空间在几分钟内回落，代价是当天一段日志缺失、归档被误删。此后验收清单里加了日志目录、保留天数（常见区间 7~30 天）和 70%~80% 预警水位。

三种做法怎么选：删、截断，还是交给轮转

同样把日志变小，三种做法的释放时机、丢日志范围和操作成本不同。判断依据不是哪种更先进，而是能不能接受丢当次日志、能不能重启或发信号、有没有人长期维护切割配置。

• 直接 rm 后让进程重开日志：释放要看重开是否成功，操作窗口常见几分钟到半小时（含验证）；代价是重开前写入的内容丢失，忘了重开空间就一直不回来。
• 截断文件（: > app.log 或 truncate -s 0）：句柄不变即可立即释放，进程不用重启；代价是历史内容清空，正在写入的偏移处理不当可能出现空洞字符，适合应急腾空间。
• logrotate 按天切割 + 保留份数 + 压缩：长期方案，保留 7~30 天是常见区间；代价是要配好 copytruncate 或 postrotate 重开信号，配错会出现切了没生效、或切完仍指向旧句柄。

经验做法是应急用截断止血，当天补上轮转，直接 rm 只在进程本来就要重启时顺带做。日志目录、保留天数、告警阈值写进部署验收清单，比上线几个月后再救火省事。

适用边界：哪些情况别靠删日志解决

这套排查适合单机或少量实例、磁盘占用以文本日志为主、允许丢弃部分历史日志的场景，尤其是刚上线不久、日志策略还没定型的项目。

反过来，如果磁盘大头是数据库数据文件、对象存储缓存或业务备份，删日志只能缓解一两天；如果行业合规对日志留存期限有硬性要求，应先按行业规范与平台规范核对留存天数，再决定能不能删；容器化且日志直接写可写层的，正确做法是改采集方式，而不是定期进容器删文件。

• 适合：日志占大头、可短暂停机或支持日志重开信号、有基础监控的环境。
• 不适合：数据文件撑满、合规留存要求明确、既不能重启也不能发信号的关键链路。

常见问题

rm 删掉日志后不重启进程，空间会自己回来吗？

多数不会，要等持有该文件的进程关闭句柄才释放；若应用支持日志重开信号，可先发信号，再用 df 复核。

df 显示满了，du 加起来差很多，是不是被入侵了？

先别下结论，常见是被删未释放的文件或目录被挂载覆盖；用 lsof +L1 与 /proc 下 fd 交叉核对，能排掉大半可能。

把日志清空和直接删文件，对磁盘的影响一样吗？

不一样。清空立即释放空间且原句柄仍有效；rm 后句柄指向已删 inode，空间要等进程关闭或重启。

容器里日志越写越大，在容器里删了宿主还是满，为什么？

日志可能写在容器可写层或宿主挂载目录，两边视角不同；按平台规范改为标准输出采集或挂持久卷更稳。

下一步建议：先在告警机器上跑 df -h、df -i、lsof +L1 三条命令并留存结果，再决定是截断止血还是切到 logrotate。若磁盘占用主要来自数据文件，或合规留存要求明确，这套做法不适用，应转向容量规划与归档策略。