lsof可查进程打开的FIFO文件：运行sudo lsof -p PID，TYPE列为FIFO、NAME为管道路径（如/tmp/myfifo）、FD含r/w/u标识；若未显示，可能因未加sudo、FIFO未被任一端成功open或两端均阻塞中。
怎么用 lsof 查到进程打开的 FIFO 文件
直接运行 lsof -p PID 就能看到该进程所有打开的文件，包括 FIFO。FIFO 在输出中类型列为 FIFO，设备号通常为 0,0，路径显示为实际的管道路径（如 /tmp/myfifo）。
常见错误现象：没看到 FIFO 行 —— 很可能因为没加 -p 限定进程，或者 FIFO 当前未被任何进程打开（open() 阻塞中），此时它只是磁盘上一个空的 p 类型文件，还没进入内核管道缓冲区，lsof 不会把它当作“已打开文件”列出。
-
lsof -p 1234：查 PID 1234 打开的所有文件，含已连接的 FIFO -
lsof /tmp/myfifo：查哪个进程正在使用这个 FIFO 路径（前提是它已被至少一端打开） - 如果 FIFO 两端都未打开，
ls -l /tmp/myfifo显示prw-r--r--，但lsof不会返回任何结果
lsof 输出里 FIFO 的关键字段怎么看
识别 FIFO 不靠文件名后缀，而看 TYPE 列是否为 FIFO，同时 NAME 列是完整路径，FD 列显示描述符编号（如 3r 表示只读、4w 表示只写）。
注意：lsof 不区分 FIFO 是阻塞打开还是非阻塞打开，也不显示当前缓冲区是否有数据；它只反映“该文件描述符是否已由内核分配并关联到 FIFO 实例”。如果看到 FD 是 3u（u 表示 read-write），说明是以 O_RDWR 模式打开的 —— 这在 FIFO 中极少见，一般只用于特殊调试场景，生产中应避免。
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
-
TYPE=FIFO是唯一可靠标识 -
FD后缀r/w对应O_RDONLY/O_WRONLY - 若
NAME显示为pipe或数字设备号而非路径，说明不是命名管道，而是匿名管道
为什么 lsof 有时查不到正在用的 FIFO
根本原因有两个：一是 FIFO 文件存在但尚未被任一进程调用 open()，二是你没用 root 权限运行 lsof。
FIFO 的“打开”行为具有强同步性：默认情况下，open(O_RDONLY) 会阻塞直到有进程以 O_WRONLY 打开同一路径；反之亦然。如果只有写端打开成功、读端还在阻塞等待，lsof 只能查到写端进程的 FIFO 条目，读端不会出现在列表中 —— 因为它的 open() 调用还没返回，文件描述符尚未生成。
- 普通用户运行
lsof可能看不到其他用户进程打开的 FIFO（权限限制） - 用
sudo lsof -p PID才能确保看到完整信息 - 若两端都处于阻塞打开状态，
lsof查不到任何一方 —— 此时需用strace -p PID看系统调用栈确认是否卡在open()
排查 FIFO 通信失败时，lsof 能帮什么忙
lsof 最实用的场景是验证“两端是否真连上了”，而不是查数据内容或缓冲区状态。
比如日志进程收不到消息，先确认写端进程是否真的打开了 FIFO：运行 sudo lsof | grep myfifo。如果只看到一行且 FD 是 w，说明读端没启动或启动失败；如果一行都没，说明写端自己都没成功打开（可能是路径错、权限不足、或 mkfifo 没执行）。
- 路径拼错会导致
open()失败，lsof自然查不到 —— 先ls -l /path/to/fifo确认文件存在且类型为p - 权限不匹配（如 FIFO 是 0600，但读端进程 UID 不同）会导致
open()报EACCES，lsof查不到该进程的条目 - 不要依赖
lsof判断 FIFO 是否“有数据”，它不提供缓冲区长度或字节数信息
lsof 视角下是“瞬态可见”的：只有当至少一端完成 open() 返回，它才真正成为“打开的文件”。这点和普通文件完全不同，也最容易被忽略。 
