删掉网关大日志后磁盘还是满，怎样识别仍被进程打开的已删除文件

Unix删除文件名不会立即关闭进程已经打开的文件。路径消失后，仍有句柄持有的数据可能继续占用空间；先识别已删除但仍打开的日志，再按服务支持的方式处理句柄生命周期。

先比对目录可见量与文件系统占用

删除动作主要去掉目录项，进程手里的文件描述符仍引用原对象。于是ls看不到文件、df却没有按预期释放，du与df也可能出现差距。若进程继续往旧描述符写，空间还会增长；创建同名新文件不会自动让旧描述符切换到新对象。

用临时FD实验重现

附件只写六十四KB临时日志，保持打开后unlink。实际观察到路径不存在、fstat大小仍为65536、链接数为零，原句柄还能读出xxx；关闭句柄后实验结束。它证明文件生命周期，不通过写满磁盘或删除生产日志来制造故障。

合成lsof记录中的deleted应结合PID、fd与大小一起读，不能仅凭路径后缀就判断某个进程可被停止。进程可能持有多个已删除文件，也可能继续写入其中一个。需要记录句柄变化与文件大小趋势，才能区分一次历史残留和仍在持续增长的对象，并选择服务支持的日志处理方式。

说明Docker托管日志不可随手改

Windows对使用中的文件删除有不同限制，程序专门标出这个平台边界，不能用Windows异常替代Unix结果。真实服务应查自己的日志重开机制和持有PID，先保存必要证据，再决定受控操作。本文不向现有服务发送信号，也不保证磁盘满只有这一种原因。

适用范围：只操作脚本创建的临时文件，不能证明生产磁盘满根因；不对现有服务发USR1或重启。

配套样本与复核入口

• run.py：独立运行程序，包含合成输入、操作和正反例断言。
• case.json：输入说明、预期任务与适用范围，便于保存和交接。
• observed.json：本次实际执行输出；临时路径、进程号和计时可能随运行变化。

请在Unix环境执行并查看path_exists、open_size、links与still_readable，四项组合说明名字与打开对象已经分离。Windows分支会明确输出删除受阻，不能和Unix参考输出逐字对照。临时文件只有六十四KB，程序不估算当前宿主机释放了多少物理块，也不把关闭句柄自动推导成真实日志故障已解决。

Linux与Python3.8以上；使用本机Unix行为。程序只对自己创建的子进程、临时路径施加改变，不接受生产路径参数。

python3 -B run.py

阅读输出时，先按case.json中的任务逐项核对网关删除日志磁盘空间不释放，再与observed.json比较。非零退出表示依赖或断言需要处理，应保留实际错误。

一手依据1（Unix删除开放文件仅去目录项，最后关闭前存储仍占用；Windows删除使用中的文件可失败。）。

继续阅读：请求完成了日志却过一会儿才出现，怎样区分Nginx日志缓冲与采集漏单；网关磁盘还有几十GB却写不了临时文件，怎样核对inode耗尽；网关stdout一直增长，怎样离线核对Docker日志轮转的磁盘预算。