FIFO命名管道在 Linux 进程间通信方案里是一个看起来很基础、实际很容易踩坑的东西。很多人面试能背出“FIFO 是带路径名的管道”但一写代码就会遇到 open 卡住、read 返回 0、write 被 SIGPIPE 杀掉这类问题。这篇文章按“先理解问题 - 创建 FIFO - 阻塞模型 - 读写边界 - 批量队列实践 - 排查链路”的顺序把命名管道从命令行到 C 源码完整拆开。适合正在学 Linux IPC 的开发者、需要在脚本里做进程配合的运维以及准备面试时想把细节讲清楚的人。接下来先从一个最容易被忽略的问题开始它到底和普通管道有什么区别。1. 先搞清楚命名管道解决的是哪个问题1.1 匿名管道和命名管道的边界普通管道pipe()只有文件描述符没有文件名。用fork()创建子进程后父子进程都能拿到这两个 fd然后一个写一个读。它的问题很明显没有血缘关系的两个进程拿不到同一个管道 fd就无法通信。FIFO 在磁盘上有一个路径名任何进程只要知道这个路径并且有权限就能 open 它。所以它解决的核心问题只有一个把管道从“父子进程专用”扩展到“任意进程可用”。数据流向还是像管道一样先进先出读走之后就不会留在文件里。这里有个常见的错误认知看到mkfifo创建出来的文件就以为它像普通文件一样可以反复写入、反复读取。实际上它不占用真正的磁盘数据块数据是写在内核缓冲区里的读端一旦把数据读走数据就没了。ls -l看到它的类型是p不是-这是判断管道节点最直接的方法。1.2 什么时候选 FIFO什么时候不选FIFO 真正适合的场景是进程间轻量的单向字节流比如一个进程往管道里写日志另一个进程消费日志。脚本 A 把任务项写进 FIFO脚本 B 从 FIFO 里拿一项处理一条。两个程序之间做简单的“消息线”不需要请求响应模型。它不适合做双向请求响应。虽然可以在两个方向各建一个 FIFO但语义上仍是单向流不如 Unix domain socket 方便。如果数据量大、消费速度跟不上写端会阻塞如果需要可靠、双向、结构化通信直接换 Unix domain socket 或共享内存不用硬用 FIFO。另外说一句硬件领域也有 FIFO比如异步 FIFO、FIFO IP 核那是数字电路里的数据缓存方案和 Linux 的命名管道虽然都叫 FIFO但实现和用法完全不同。这篇文章只聊 Linux 进程间通信的命名管道。2. 从创建到第一次收发三分钟跑通 FIFO2.1 用 mkfifo 命令创建命名管道创建 FIFO 有两条路命令行使用mkfifomkfifo /tmp/myfifo ls -l /tmp/myfifo输出里能看到prw-r--r-- 1 user user 0 Apr 14 10:00 /tmp/myfifo第一个字符是p表示管道。文件大小显示 0不占用数据块。Linux 下还可以用mkfifo -m 0666 /tmp/myfifo指定权限位不加-m时受当前 umask 影响默认可能不是 0666。创建之后可以立刻做一次 shell 级验证。开两个终端终端 A 执行cat /tmp/myfifo终端 B 执行echo hello fifo /tmp/myfifo回看终端 A会输出hello fifo。这个例子值得多跑几遍因为你能直观体会到阻塞先执行终端 A 的cat它会卡在 open 上直到终端 B 打开写入A 才拿到数据。2.2 用 mkfifo() 函数在代码里创建命令行能做的事代码里也都能做。创建 FIFO 的核心函数是#include sys/types.h #include sys/stat.h int mkfifo(const char *pathname, mode_t mode);成功后返回 0失败返回 -1。常见失败原因有三种路径已存在返回EEXIST没有权限返回EACCES父目录不存在或路径错误返回ENOENT。所以生产代码里要先判断errno不能看到EEXIST就当成致命错误。if (mkfifo(/tmp/myfifo, 0666) -1) { if (errno ! EEXIST) { perror(mkfifo); exit(EXIT_FAILURE); } // EEXIST 只代表节点已存在可能是 FIFO也可能是普通文件 }这里有个坑EEXIST不一定代表“已经有个 FIFO 了”也可能是同名普通文件。稳妥的做法是用stat()判断st_mode确认是S_ISFIFO()再继续。2.3 一个最小 C 语言收发示例我建议第一次用 C 写时把程序拆成两个独立文件一个只负责写一个只负责读这样能避免“自己读自己写”的混乱。写端writer.c#include stdio.h #include stdlib.h #include string.h #include errno.h #include fcntl.h #include sys/stat.h #include sys/types.h #include unistd.h #define FIFO_PATH /tmp/myfifo int main(void) { if (mkfifo(FIFO_PATH, 0666) -1 errno ! EEXIST) { perror(mkfifo); exit(EXIT_FAILURE); } printf(writer: opening FIFO for write...\n); int fd open(FIFO_PATH, O_WRONLY); if (fd -1) { perror(open); exit(EXIT_FAILURE); } const char *msg hello from writer; write(fd, msg, strlen(msg) 1); printf(writer: sent %lu bytes\n, strlen(msg) 1); close(fd); return 0; }读端reader.c#include stdio.h #include stdlib.h #include string.h #include fcntl.h #include sys/stat.h #include sys/types.h #include unistd.h #define FIFO_PATH /tmp/myfifo int main(void) { printf(reader: opening FIFO for read...\n); int fd open(FIFO_PATH, O_RDONLY); if (fd -1) { perror(open); exit(EXIT_FAILURE); } char buf[1024] {0}; ssize_t n read(fd, buf, sizeof(buf)); if (n 0) { printf(reader: received %zd bytes: %s\n, n, buf); } else if (n 0) { printf(reader: EOF, all writers closed\n); } else { perror(read); } close(fd); return 0; }编译运行gcc writer.c -o writer gcc reader.c -o reader ./reader # 先运行会阻塞在 open ./writer # 再运行writer 返回后 reader 输出内容这里有个很容易理解的阻塞点读端open(O_RDONLY)会阻塞直到写端也 open 成功写端open(O_WRONLY)也会阻塞直到读端 open 成功。所以两个进程谁先跑都会卡在 open但一旦对端出现两边同时返回。这个机制是 FIFO 好用的起点也是“卡住”问题的源头。3. 图解 源码阻塞模型和内核缓冲区3.1 数据到底存在哪里先把模型画出来。FIFO 在文件系统里只有一个路径名真正的数据不在这个路径名里而在内核的管道缓冲区中。写进程 读进程 | | | fd open(/tmp/myfifo, O_WRONLY) | fd open(/tmp/myfifo, O_RDONLY) v v | | | ----------------- | | write() - | 内核管道缓冲区 | - read() | ----------------- | | 先进先出读走即删除 |读端从缓冲区取数据取完缓冲区就空出位置。这个缓冲区是环形队列式的结构有容量上限。在常见 x86 Linux 上未显式设置时管道缓冲区默认大约 64KB也就是 16 个内存页。具体数值不同内核可能不同可以通过fcntl(fd, F_SETPIPE_SZ)调整上限受限于系统的pipe-max-size配置。知道缓冲区大小很重要因为很多问题都围绕它展开写端写入数据超过缓冲区剩余空间时write()会阻塞直到读端取走数据腾出空间。如果数据量小比如一条几百字节的消息读写速度又匹配你会觉得 FIFO 非常顺滑。一旦写端产生数据的速度远大于读端消费速度CPU 可能不高但进程会长时间卡在write()上。所以不要把 FIFO 当成无限缓冲的队列。它适合“生产速度与消费速度基本匹配”的流不适合“生产者疯狂灌消费者慢慢拿”的堆积型场景。3.2 open() 的四种方式和阻塞语义这一节是 FIFO 最容易出错的地方。open 的阻塞行为可以整理成一张表打开方式没有对端时的行为设置 O_NONBLOCK 后O_RDONLY阻塞直到有写端打开立即成功O_WRONLY阻塞直到有读端打开立即失败errno 为 ENXIOO_RDWRLinux 下立即成功进程自己既当读端又当写端立即成功默认情况下单纯用open(FIFO_PATH, O_WRONLY)而没有读者进程会一直卡在 open 返回上这不是死锁是在等对端。很多人写脚本时先启动生产者再启动消费者生产者就在 open 处卡住看起来像“程序没反应”其实是顺序问题。想避免 open 卡住要么保证对端先启动要么加O_NONBLOCK。加了O_NONBLOCK后写端 open 如果没有读者会直接返回 -1并设置errno为ENXIO。这是很多程序判断“对端是否存在”的方法。不过要提醒一点O_NONBLOCK只是让 open 不阻塞不解决数据堆积。如果写端持续写入、读端不消费写端照样会阻塞在write()上。3.3 阻塞的 read 和 write 到底返回什么读阻塞读端打开后如果缓冲区里没有数据read()会阻塞直到写端写入字节或者所有写端全部关闭。写端全部关闭时read()返回 0表示 EOF。这是消费端判断“对方走了”的关键信号。写阻塞写端写入时如果缓冲区满了write()会阻塞直到有空间。写端写入时如果读端早已关闭内核会向写进程发送SIGPIPE。默认情况下进程被信号终止如果不想死就要自己忽略或处理SIGPIPE并处理write()返回 -1、errnoEPIPE的情况。这段语义面试里经常考实际排错也离不开。举个例子一个守护进程从 FIFO 读数据另有一个临时任务往 FIFO 写一条消息写完后关闭。守护进程read()会读到这条消息然后下次read()返回 0就认为“没有写者了”如果不处理 EOF守护进程可能退出。这是写 FIFO 队列时最经典的坑。解决办法是让某个读端或写端长期持有 fd不让全链路出现“所有写端都关闭”的时刻。或者读端程序显式处理read() 0重开 FIFO继续等下一批数据。4. 参数、边界和判断标准把语义读透4.1 一次能写多少会不会粘包FIFO 是字节流不是消息队列。它没有“消息边界”每次write()写进来的数据read()不会自动按一次 write 来切分。比如写端连续写两次AB和CD读端可能一次read()读到ABCD也可能先读到A再读到BCD。这是字节流的正常行为。但 POSIX 规定了一个原子性保证对管道/FIFO 的一次write()如果字节数不超过PIPE_BUF通常为 4096 字节并且写端是阻塞模式那么这次写入操作与其它写端并发时是原子的不会被穿插切碎。换句话说单条消息小于或等于PIPE_BUF多个写端同时写读端看到的每条数据是完整的。单条消息超过PIPE_BUF写操作可能被其它写操作穿插读端需要靠自己的协议来区分消息边界。实际项目里如果多个写进程都要往同一个 FIFO 写而你又需要保持“一条消息完整”的语义我建议每条消息控制在 4096 字节以内并且自己加消息头比如“固定长度头部 负载”或者用行分隔、JSON 换行等结构化形式。不要依赖 FIFO 自带边界它没有。4.2 判断“写出去了没”write 返回值和错误write()返回实际写入的字节数。在阻塞模式下对 FIFO 的一次 write 通常能完整写入如果写的是 4096 字节以内的单条记录基本可以认为“要么大部分写入要么阻塞等待”。返回 -1 时看 errnoerrno含义处理建议EAGAIN非阻塞模式下缓冲区暂满等一会重试或换成阻塞模式EPIPE读端已关闭忽略 SIGPIPE 后检查对端是否还活着EINTR被信号打断通常重试 write 即可还有一点很容易忽略SIGPIPE。默认情况下写端往已关闭的读端写数据进程会被信号直接杀死你根本看不到EPIPE。所以服务端程序通常要signal(SIGPIPE, SIG_IGN)或sigaction忽略它再通过write的返回值判断连接状态。这个经验在处理长时间运行的服务程序时特别重要。4.3 别把 FIFO 当普通文件权限、路径和生命周期FIFO 虽然显示在文件系统里但很多普通文件的规则不适用。列出几个常见的判断标准ls -l显示p文件大小恒为 0不需要判断大小来读数据。open()之前路径必须存在否则返回ENOENT。FIFO 没有自动创建能力谁创建、何时创建必须提前约定好。rm一个 FIFO 节点不会影响已经打开的 fd。已经打开写端和读端的进程还能正常通信只是新的 open 会失败。权限影响 open。如果用户没有写权限open(O_WRONLY)返回EACCES。多进程共用时建议用0666配 umask 控制或放到专用目录。FIFO 不会自动消失进程退出后节点还在下次还要用记得先unlink或rm否则多次运行会复用旧节点。一句话总结FIFO 的生命周期由文件系统节点和内核缓冲区共同决定节点可以长期存在内部数据是瞬态的。5. 拿 FIFO 做进程编排任务队列和注意事项5.1 一个简单的生产者-消费者队列FIFO 最常见的实用场景是做一个轻量任务队列。比如一个消费进程从 FIFO 里不断读任务另外几个生产者把任务行写进去。消费者queue_reader.sh#!/bin/bash FIFO/tmp/jobqueue mkfifo $FIFO 2/dev/null || true while true; do if read -r line $FIFO; then echo process task: $line fi done生产者queue_writer.sh#!/bin/bash FIFO/tmp/jobqueue echo task-001 $FIFO先启动消费者再启动生产者。这里有个值得注意的行为消费者脚本里read -r line $FIFO是一次性打开、读取、关闭当生产者写完并关闭后消费者下一次 open 又会阻塞等待新的写端。这样设计可以应付“多个临时生产者”的模式但要小心 open 竞争。更稳定的方式是消费者用一个长期持有的读 fdexec 3 $FIFO while IFS read -r line 3; do echo process task: $line done这样读 fd 一直打开消费者不会因为某个写者退出而立刻读到 EOF 退出。但要注意所有写端都关闭时消费者仍然会读到 EOF。所以要么长期持有一个“占位写者”要么在 while 之后重新打开读端继续等。这就是 FIFO 队列设计里最绕、也最值得自己动手验证的地方。5.2 避免死锁和写阻塞的三个原则跑批量任务时我一般会按这三个原则来设计先读端后写端。保证消费者先启动生产者不会在 open 时阻塞。脚本里可以用一个准备阶段先启动消费进程再发任务。控制生产速率。如果任务很多不要用一个循环疯狂写 FIFO缓冲区满了会阻塞。要么降低写入速度要么让消费者提高消费速度要么用多个消费者并发读。给写端设置超时或非阻塞。生产环境里如果消费者异常退出写端就可能无限期阻塞。这种场景下要根据业务取舍用非阻塞 EAGAIN 重试或用O_WRONLY | O_NONBLOCK先探测对端是否存在再做数据写入。这三个原则能避开大多数“脚本跑着跑着卡住”的问题。尤其是第一条很多人把生产者脚本先投到 crontab 里消费者还没起来生产者就卡在 open 上最后联调时怎么都找不到原因。5.3 日志、超时和清理策略把 FIFO 用在长期服务里还需要考虑这些日志。读端要记录每次 read 的字节数、任务名和异常退出点不要只是read完就完事。批量任务失败时第一件事就是看日志里“哪条任务读到一半断了”。超时。如果担心读写阻塞可以在open时加O_NONBLOCKread返回EAGAIN就 sleep 重试也可以把 fd 放进poll()/epoll()设置超时时间。FIFO 的 fd 支持 poll这是很实用的能力。清理。进程退出时记得unlink(FIFO_PATH)避免遗留节点。多实例部署时每个实例最好用独立路径比如/tmp/queue_${PID}.fifo否则两个实例可能互相抢数据。这些策略不是 FIFO 的语法知识而是落地时真正决定项目稳定性的部分。面试里通常不会考但实际出问题全在这里。6. 遇到问题先别改代码一套排查链路6.1 根据现象定位根因FIFO 的报错现象其实很有限但不看日志时特别容易绕圈。我建议按这个顺序排查看现象卡住无输出进程被杀还是数据错乱。看 FIFO 节点ls -l /tmp/myfifo确认类型是p权限够不够路径是否一致。看谁打开了 fdlsof /tmp/myfifo或fuser /tmp/myfifo确认读写两端是否都活着。看系统调用strace -e traceopen,read,write -p pid能看到进程到底阻塞在哪个调用上。看 errno返回 -1 时把 errno 打出来对照 EAGAIN、EPIPE、ENXIO 判断。看读端程序对 EOF 的处理read() 0是所有写端关闭的信号很多退出问题都出在这里。6.2 经典场景对照表现象最可能原因第一优先排查写端 open 一直卡住没有读端