确认进程是否正在用管道通信，须检查其/proc/[PID]/fd/下是否存在pipe:[数字]符号链接，而非仅依赖ps中|符号；因匿名管道无路径名，仅能通过inode号匹配验证。
怎么确认某个进程正在用管道通信
不能只看 ps 输出里的命令行是否带 |，那只是 shell 创建的匿名管道，进程本身可能早已关闭读写端。真正要判断“当前”是否在用管道通信，得查它打开的文件描述符里有没有 pipe: 类型的项。
最直接的办法是：ls -l /proc/[PID]/fd/ | grep pipe。如果看到类似 lr-x------ 1 root root 64 Jul 9 16:00 3 -> 'pipe:[123456]' 这样的输出，说明该进程确实持有一个管道 fd。
-
[PID]必须替换成真实进程号，别直接敲方括号 - 输出中
pipe:[数字]后面的数字是内核分配的管道 inode 号，同一管道两端的进程会显示相同的数字 - 如果没 grep 出结果，不代表没用过管道——可能是已关闭、或根本没创建过
为什么 lsof | grep pipe 容易漏掉关键信息
lsof 默认不显示所有进程的 fd，尤其对非 root 用户运行的进程，权限不足时会跳过很多条目，导致 grep pipe 看不到实际在用的管道。
更可靠的做法是：先用 ps -eo pid,comm,args | grep [关键词] 找到目标进程 PID，再直接进 /proc/[PID]/fd 查。这样绕过权限过滤，也避免了 lsof 自身的缓冲和采样延迟。
-
lsof -U只列 Unix 域套接字，不包括管道，别混用 -
lsof -p [PID]比全局lsof | grep更准，但依然受用户权限限制 - 管道没有路径名，
lsof显示的NAME列通常是空或pipe，不如/proc/[PID]/fd的符号链接直观
匿名管道 vs 命名管道，状态查看方式完全不同
匿名管道（shell 中的 |）只存在于父子进程之间，生命周期随进程结束自动释放，没有文件系统路径，只能通过 /proc/[PID]/fd 查 inode 号匹配。
命名管道（mkfifo 创建的 FIFO 文件）则不同：它是个真实文件，ls -l /path/to/fifo 能看到类型为 p；用 lsof /path/to/fifo 或 fuser /path/to/fifo 可直接列出所有打开它的进程。
- 匿名管道的 inode 号在父子进程中一致，可用于交叉验证通信关系
- 命名管道被打开后，
ls -l会显示读写权限（如prw-r--r--），而匿名管道永远不暴露路径 -
fuser -v /path/to/fifo比lsof更快，且明确标出READ/WRITE方向
管道缓冲区满或阻塞时，read/write 系统调用状态怎么查
仅靠查看 fd 无法知道管道当前是否卡住。真要诊断阻塞，得结合 strace -p [PID] 观察系统调用栈——如果卡在 read(3, ...) 或 write(4, ...) 且长时间不动，大概率是另一端没读/没写，或缓冲区满（默认 65536 字节，4.9+ 内核可调）。
-
strace输出里出现--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, ...} ---表示子进程退出，可能导致父进程read返回 0（EOF），不是错误 - 缓冲区大小可用
cat /proc/sys/fs/pipe-max-size查，修改需 root 权限：echo 1048576 > /proc/sys/fs/pipe-max-size - 用
ss -p查不到管道，它只管网络套接字，别误用
查管道状态这事，本质是查进程打开了哪些 fd 并识别其类型。别指望一个命令全搞定，得根据匿名/命名、权限高低、是否需实时跟踪来选工具。最稳的路径永远是：PID → /proc/[PID]/fd → 看 pipe:[xxx] 或 FIFO 路径。
