最可靠方式是直接读取/proc/[pid]/fd/目录：用ls -l列出所有数字fd项，readlink查看其指向，过滤掉stdin/stdout/stderr等伪路径，结合stat或readlink失败判断是否已关闭，避免依赖lsof等外部工具。
怎么查某个进程当前打开的 fd 列表
直接读 /proc/[pid]/fd/ 是最轻量、最可靠的方式，不需要额外工具，也不受权限限制（只要能访问该进程的 proc 目录）。每个数字子项就是一个打开的 fd，readlink 能看出它指向什么。
- 先拿到 PID，比如
pgrep nginx或pidof mysqld - 执行
ls -l /proc/1234/fd/，输出类似：0 -> /dev/pts/03 -> socket:[123456]4 -> /var/log/nginx/access.log - 想只看真实文件（排除 stdin/stdout/stderr），加过滤：
ls -l /proc/1234/fd/ | awk '$NF !~ /^\/dev\/pts\/|^\/proc\/|^\/sys\// {print}' - 注意：符号链接失效（如
readlink: No such file or directory）通常意味着 fd 已关闭但未被回收，属于内核延迟释放，不是泄漏
为什么 lsof -p PID 有时不准或报错
lsof 看起来全面，但实际容易出问题：权限不足时跳过部分条目；遇到已关闭但未清理的 fd 会显示 can't identify protocol 或直接漏掉；某些容器环境或 seccomp 限制下根本跑不起来。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 常见错误：
lsof: no pwd entry for UID xxx—— 不影响计数，但说明用户数据库缺失，lsof -n -p PID可绕过 DNS/UID 解析 - 统计总数别用
lsof -p PID | wc -l，它包含表头和空行；稳妥写法：lsof -n -p PID 2>/dev/null | grep -v "COMMAND" | wc -l - 真正要定位泄漏点，优先用
lsof -n -p PID | awk '{print $9}' | sort | uniq -c | sort -nr | head -5，看哪些路径重复最多
cat /proc/[pid]/status 里的 FDs 和 FDSize 是啥
这两个字段是内核快照值，非实时精确计数，但适合快速巡检。它们来自同一内存结构，比遍历 /proc/[pid]/fd/ 开销小得多。
- 执行
cat /proc/1234/status | grep -E 'FDs|FDSize'，输出形如：FDSize: 256FDs: 42 -
FDs是当前已分配且活跃的 fd 数（≈ls /proc/[pid]/fd/ | wc -w） -
FDSize是内核为该进程预分配的 fd 槽位总数（通常是 256、1024、2048 等 2 的幂），不是限制值，只是内部哈希表大小 - 如果
FDs接近FDSize，说明进程频繁扩容 fd 表，可能有泄漏或设计缺陷
怎么确认某个 fd 是否真在用
光看 /proc/[pid]/fd/ 里有链接不够，得验证它是否还绑定有效资源。很多“僵尸 fd”其实是 close() 调用后未被内核立即回收的残留。
- 对 fd 3 执行：
readlink /proc/1234/fd/3，若返回No such file or directory，大概率已关闭 - 更准一点：用
stat /proc/1234/fd/3 2>/dev/null | grep -q "No such file"判断是否存在 - 如果
readlink成功但目标路径是socket:[123456]或anon_inode:[eventpoll]，说明是网络连接或 epoll 实例，属正常活跃状态 - 真正可疑的是大量指向
pipe:[...]或inotify却长期不读写的 fd，这类容易堆积
