最准、最轻量的方式是直接查看/proc/[pid]/fd目录,每个数字子项对应一个真实分配的文件描述符,符号链接目标即打开资源路径,实时映射且不依赖外部工具或权限。

直接看 /proc/[pid]/fd 目录是最准、最轻量的方式——它不依赖外部工具,也不受权限限制(只要能读该进程的 proc 条目),且每个数字子项就对应一个真实分配的 fd。
怎么看某个进程当前用了哪些文件描述符
Linux 内核为每个进程在 /proc/[pid]/fd 下维护一组符号链接,编号即 fd 号,目标即打开的资源路径。这不是快照或统计值,而是实时映射。
- 先拿到 PID:比如
pgrep nginx或pidof mysqld - 执行
ls -l /proc/1234/fd(把 1234 换成实际 PID);输出里每行一个 fd,如3 -> socket:[123456]或7 -> /var/log/app.log - 想只看纯数字 fd(排除
cwd、root等伪条目):用ls /proc/1234/fd | grep -E '^[0-9]+$' | wc -w - 注意:
0、1、2几乎总存在(stdin/stdout/stderr),别误判为泄漏
为什么 lsof -p [pid] | wc -l 常不准
lsof 输出包含表头、空行、甚至因权限不足跳过的条目,且默认会列出所有类型(包括未真正“打开”的 eventpoll、inotify 实例),导致计数虚高或漏报。
在无 root/sudo 权限的环境(云容器、VPS、隔离主机)中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景:...
- 常见现象:
lsof -p 1234 | wc -l返回 87,但ls /proc/1234/fd | wc -w是 82 —— 多出的 5 行通常是 lsof 自己的元信息或被截断的 socket 描述 - 更可靠的做法是加
-F f输出精简 fd 列表:lsof -p 1234 -F f 2>/dev/null | grep '^f' | wc -l - 但如果你没 root 权限,
lsof很可能连自己用户的其他进程都列不全;而/proc/[pid]/fd只要进程属你、且没被 ptrace 保护,就能读
/proc/[pid]/status 里的 FDs 字段靠不靠谱
cat /proc/1234/status | grep -E 'FDs|FDSize' 显示的是内核缓存的近似值,不是实时精确计数,尤其在高并发短连接场景下容易滞后。
-
FDs: 123表示“上次更新时已用数量”,但可能刚 close 了 5 个,这里还没刷新 -
FDSize: 1024是该进程当前 fd 表分配的槽位总数,不等于 ulimit 限制(比如 ulimit -n 65536,但 FDSize 可能还是 1024 —— 内核按需扩容) - 它适合快速巡检,但排查“fd 突然涨到 65535 报错”时,必须回退到
/proc/[pid]/fd目录逐个确认
真正关键的不是数字本身,而是每个 fd 链接指向什么:如果大量 socket:[...] 或 anon_inode:[eventpoll] 却没有对应业务连接,大概率是应用没正确 close 或连接池配置过激;如果看到一堆 /tmp/xxx.tmp 且 PID 不变,就得查代码里文件是否漏 fclose。










