最准方法是直接查看 /proc/[pid]/fd 目录，它由内核实时维护，每个数字条目对应一个当前已分配的文件描述符；执行 ls -l /proc/[pid]/fd 可见全部 fd 及其指向目标，ls /proc/[pid]/fd | wc -w 精确统计数量，比 lsof 更轻量、无权限限制且不漏项。
怎么查某个进程正在用哪些 fd
直接看 /proc/[pid]/fd 目录最准，它就是内核实时维护的符号链接集合，每个数字条目对应一个已分配的 fd。不是“可能打开”，而是“此刻内核认为它正持有”。
- 先拿到 PID：比如
pgrep nginx或pidof redis-server - 执行
ls -l /proc/1234/fd（把 1234 换成真实 PID），输出里每行一个 fd，例如3 -> socket:[123456]或7 -> /var/log/app.log - 想只看数量？用
ls /proc/1234/fd | wc -w—— 它比lsof -p 1234 | wc -l更轻量、不依赖权限、不漏统计（lsof在非 root 下常因权限不足跳过部分条目）
怎么确认 fd 具体指向什么资源
/proc/[pid]/fd 里的箭头（->）右边就是目标路径，但有些类型没法直接显示文件名，比如 socket、eventpoll、anon_inode，得结合 /proc/[pid]/fdinfo/[fd] 看细节。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 对普通文件或设备：
readlink /proc/1234/fd/5就能直接输出路径 - 对 socket：
cat /proc/1234/fdinfo/6会显示socket:[123456]，再用ss -tunp | grep 123456可定位到监听地址和端口 - 对 epoll 或 timerfd：
cat /proc/1234/fdinfo/8里会有type: eventpoll或type: timerfd，说明这是内核事件机制句柄，不是文件
为什么 cat /proc/[pid]/status 里的 FDs 不等于 ls /proc/[pid]/fd | wc -w
FDs 字段是内核估算值，来自进程描述符表的位图扫描，而 /proc/[pid]/fd 是实际挂载的符号链接目录——后者才是真实分配数。两者差值常见于刚 close() 但内核尚未回收的 fd。
-
cat /proc/1234/status | grep FDs输出类似FDs: 42，但ls /proc/1234/fd | wc -w返回 45，说明有 3 个 fd 处于“已关闭但未释放”状态 - 这种延迟在高并发短连接服务（如 Node.js HTTP server）中很常见，一般几毫秒内自动清理；如果持续差值 >10，就要怀疑 fd 泄漏了
- 别信
FDSize：它是内核预分配的槽位大小（比如 1024），不代表当前用了多少
systemd 服务里 fd 分配不生效？去 /proc/[pid]/limits 确认
ulimit -n 和 /etc/security/limits.conf 对 systemd 启动的服务基本无效，真正起作用的是进程启动时继承的 limits，必须以 cat /proc/[pid]/limits 为准。
- 查 nginx 主进程 limits：
cat /proc/$(pgrep nginx | head -n1)/limits | grep "Max open files" - 如果看到
Max open files 1024 1024 files，说明没生效，哪怕你在nginx.service里写了LimitNOFILE=65535，也可能是写错了位置（必须在[Service]段下）或没重载配置（systemctl daemon-reload && systemctl restart nginx） - 容器场景更要小心：
docker run --ulimit nofile=65536:65536才能传给容器内进程，宿主机的 ulimit 不自动继承
socket:[...] 却不知道连的是谁、有没有泄漏。这时候得靠 ss -tunp 和 lsof -nP -i 交叉验证，而不是只盯着数字。
