加 sudo 仍查不到 lsof /path/to/file，主因是路径未写绝对路径、目标为软链接未加 -L、文件被替换导致 inode 变化、位于 bind mount/overlayfs 等特殊挂载下，或 FD 列未显示写入标识（如 REGw）；应优先用 sudo lsof -L /full/path/to/file 重试。
直接用 lsof /path/to/file，但 90% 的“查不到”问题都出在权限和路径上，不是命令失效。
为什么加了 sudo 还是查不到？
常见错误现象：执行 sudo lsof /var/log/nginx/access.log 仍无输出，但 tail -f 明明在跑。
- 路径不是绝对路径——
lsof ./access.log或lsof access.log一定失败，必须写全路径，如/var/log/nginx/access.log - 目标是软链接，而你查的是链接本身——默认不跟随，得加
-L：sudo lsof -L /etc/nginx/conf.d/default.conf - 文件刚被
mv或cp --reflink替换过，inode 已变，旧路径查不到，得按当前ls -i确认的路径重试 - 路径位于 bind mount 或 overlayfs 下（比如容器中 /var/log/journal），
lsof查的是内核实际挂载点，不是你ls看到的路径
如何确认进程真在写这个文件，而不是只 cwd 或只读打开？
lsof 输出里 FD 列才是关键判断依据，不能只看 NAME 是否匹配。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
-
cwd表示该进程当前工作目录是这个路径，不代表它在读写该文件 -
txt表示它是可执行文件或共享库，一般不用管 -
REG后带w（如REGw）或u（REGu）才说明正在写入；REG单独出现通常是只读打开 - NAME 列末尾有
(deleted)，说明文件已被rm，但进程还握着 fd，磁盘空间不会释放
没有 lsof 怎么办？直接翻 /proc/PID/fd/
某些最小化系统、容器或安全加固环境里没装 lsof，但 /proc 是内核原生接口，永远可用。
- 先用
ps aux | grep keyword或pgrep -f nginx找疑似 PID - 再执行
ls -l /proc/<code>PID/fd/ | grep "filename" —— 注意这里要匹配完整文件名或路径片段 - 如果看到类似
lr-x------ 1 root root 64 Sep 8 11:24 12 -> /var/log/app.log (deleted)，就确认了占用关系 - 比
lsof更底层，但无法跨进程自动聚合，适合已知范围窄的排查
最常被忽略的一点：查不到时别急着换工具，先 sudo lsof -L /full/path/to/file 重试一次——路径精度和权限覆盖，基本覆盖了所有真实场景中的盲区。
