当/proc//fd下出现大量标有(deleted)的文件描述符，说明进程曾打开文件后被unlink但未关闭fd，常见于nginx、java等长期运行服务；需用lsof或for循环统计各pid的deleted fd数量，再结合ls -l /proc//fd/、cat /proc//cmdline及lsof -p 定位具体文件与进程类型，区分正常日志轮转与真实资源泄漏。
当 /proc/<pid>/fd</pid> 下看到大量标有 (deleted) 的文件描述符时，说明该进程曾打开过某些文件，之后这些文件被 unlink（比如被 rm 或日志轮转工具删除），但进程仍持有打开状态的 fd，未关闭。这类情况常见于长期运行、未正确处理文件关闭逻辑的服务（如 nginx、java 应用、rsyslog、自研守护进程等）。关键不是“删了还留着”，而是“为什么没释放”——这往往意味着资源泄漏或逻辑缺陷。
先快速定位嫌疑进程
直接找 fd 数量异常多的进程：
- 用
lsof | grep deleted | awk '{print $2}' | sort | uniq -c | sort -nr | head -10统计各 PID 持有 (deleted) fd 的数量 - 或更精准：
for pid in /proc/[0-9]*; do cnt=$(ls -l "$pid/fd" 2>/dev/null | grep -c '\(deleted\)'); [ "$cnt" -gt 10 ] && echo "$pid → $cnt"; done | sort -k3 -nr（把阈值 10 换成你关心的数字，比如 50 或 100） - 重点关注常驻型进程：java、nginx、python、node、rsyslogd、supervisord 子进程、docker 容器内进程等
确认具体是哪些 (deleted) 文件及来源
进到目标 /proc/<pid>/fd/</pid> 目录后：
- 用
ls -l查看所有 fd，带(deleted)的条目会显示类似：lr-x------ 1 user user 64 ... 0 -> /var/log/app.log (deleted) - 注意箭头后的路径（即使标 deleted，原始路径通常还能看出归属，比如
/tmp/xxx.log、/var/log/nginx/access.log） - 结合
cat /proc/<pid>/cmdline | tr '\0' ' '</pid>看启动命令，判断是否是日志服务、web server、批处理脚本等 - 用
lsof -p <pid> | grep deleted</pid>可补全文件类型（REG、CHR、FIFO 等）和访问模式（w、u、r）
判断是否真有问题，还是正常行为
不是所有 (deleted) 都代表故障：
-
正常情况：程序打开日志文件后，由 logrotate 发起
kill -USR1重载，旧文件被 unlink，新日志写入新文件，但旧 fd 仍保持 open 直到当前写操作完成——这是设计使然，只要 fd 数不持续增长就 OK -
异常信号：同一类文件（如
/tmp/xxx.tmp (deleted)）数量随时间线性上升；或 fd 总数接近ulimit -n上限；或进程 RSS 内存同步上涨 - 可对比历史：用
watch -n 5 'ls -l /proc/<pid>/fd/ 2>/dev/null | grep deleted | wc -l'</pid>观察 5 分钟内是否递增
进一步追查代码或配置根源
锁定进程后，需结合其类型做针对性分析：
-
Java 应用：检查是否用
FileOutputStream或RandomAccessFile打开文件后未close()，尤其在异常分支遗漏；用jstack <pid></pid>看线程栈中是否有 IO 操作挂起 -
Nginx：确认
access_log/error_log是否配了buffer或gzip，某些旧版本在 reopen 日志时存在 fd 泄漏；升级或加worker_rlimit_nofile缓冲 -
Python 脚本：搜
open(、tempfile.mkstemp、subprocess.Popen（stdout/stderr 未 close）；优先改用with open(...) as f: -
自研 C/C++ 服务：检查
open()后是否匹配close()，尤其在多线程、信号处理、错误跳转路径中遗漏
本质上，(deleted) 本身无害，但它是“文件句柄未释放”的可见表征。重点不是删它，而是找到为何不关——从 fd 增长趋势、对应文件类型、进程生命周期三方面交叉验证，就能准确定位作祟模块。
