当 /proc//fd 下出现大量标有 (deleted) 的文件描述符，说明进程曾打开文件后被 unlink 但未关闭 fd，常见于 nginx、Java 等长期运行服务；需用 lsof 或 for 循环统计各 pid 的 deleted fd 数量，再结合 ls -l /proc//fd/、cat /proc//cmdline 及 lsof -p 定位具体文件与进程类型，区分正常日志轮转与真实资源泄漏。
当 /proc/ 下看到大量标有 (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/ 目录后：
- 用
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/看启动命令，判断是否是日志服务、web server、批处理脚本等/cmdline | tr ' ' ' ' - 用
lsof -p可补全文件类型（REG、CHR、FIFO 等）和访问模式（w、u、r）| grep deleted
判断是否真有问题，还是正常行为
不是所有 (deleted) 都代表故障：
- 正常情况：程序打开日志文件后，由 logrotate 发起
kill -USR1重载，旧文件被 unlink，新日志写入新文件，但旧 fd 仍保持 open 直到当前写操作完成——这是设计使然，只要 fd 数不持续增长就 OK - 异常信号：同一类文件（如
/tmp/xxx.tmp (deleted)）数量随时间线性上升；或 fd 总数接近ulimit -n上限；或进程 RSS 内存同步上涨 - 可对比历史：用
watch -n 5 'ls -l /proc/观察 5 分钟内是否递增/fd/ 2>/dev/null | grep deleted | wc -l'
进一步追查代码或配置根源
锁定进程后，需结合其类型做针对性分析：
- Java 应用 ：检查是否用
FileOutputStream或RandomAccessFile打开文件后未close()，尤其在异常分支遗漏；用jstack看线程 栈中是否有 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 增长趋势、对应文件类型、进程生命周期三方面交叉验证，就能准确定位作祟模块。
