Linux下基于select监听管道捕获子进程输出时stderr丢失的问题排查

子进程stderr输出的实际去向 #

• 从代码逻辑看，子进程fork完成后，先通过dup2把pipe_stderr管道的写端绑定到进程的标准错误（即STDERR_FILENO，fd=2），之后才execv启动Shell脚本。
• Shell脚本中echo "++stderr.." >> /dev/stderr的操作，本质是打开/dev/stderr（对应进程当前的fd=2）写入内容，理论上所有stderr输出都应该进入pipe_stderr的内核管道缓冲区。
• 实际上这些stderr内容完全没有丢失：因为管道写端的打开引用计数不为0，Shell脚本的写入操作不会被拒绝，所有stderr输出都会被暂存在内核的管道缓冲区中。只是父进程从来没有读取这部分数据，才导致输出里完全看不到stderr的内容。如果持续运行，当64KB默认大小的管道缓冲区被写满后，Shell的stderr写入操作会被阻塞，最终导致整个脚本卡住。

父进程select逻辑捕获不到stderr的核心原因 #

父进程的实现存在两个违反POSIX规范的错误，直接导致stderr流被彻底漏听：

1. select监听集合的错误复用
   • 按照select()的官方定义，系统调用返回时，内核会直接修改传入的fd_set结构：仅保留处于就绪状态的文件描述符，所有非就绪状态的fd都会被从集合中清除。
   • 原代码仅在进入主循环前，做了一次FD_ZERO+FD_SET把stdout、stderr两个管道的读端加入监听集合，后续循环中再也没有重置过这个集合。
   • 第一次调用select时，Shell脚本启动后，stdout内容率先写入管道触发stdout读端就绪；此时stderr内容还未完成写入，stderr读端没有就绪状态，因此内核直接把pipe_stderr[0]从监听集合中移除。
   • 进入后续循环后，监听集合里已经完全没有stderr读端了，哪怕之后持续有stderr内容写入管道缓冲区，select也根本不会监听这个fd，自然永远无法感知到stderr的输入事件，对应的FD_ISSET判断永远不会触发。
2. select超时参数的错误复用
   • 原代码把timeout结构体定义在循环外部，同样按照POSIX规范，select()返回时会修改timeout结构体的值，将其更新为本次调用剩余的等待时间。
   • 原代码中timeout初始值为17秒，因为stdout每秒都会有新数据触发select提前返回，timeout值会被不断扣减。这个问题目前被高频的stdout输入掩盖了——如果stdout输入停止，select的超时时间会被快速消耗，出现提前超时的异常。

快速修复方案 #

在父进程的主循环中，每次调用select之前，重新完成监听集合的初始化和fd添加，同时在循环内部重新初始化timeout值即可：

while(1){
    puts("Select");  
    // 每次循环重置监听集合
    FD_ZERO(&set); 
    FD_SET(pipefd[0], &set); 
    FD_SET(pipe_stderr[0], &set); 
    // 每次循环重置超时时间
    timeout.tv_sec = 17; 
    timeout.tv_usec = 0; 

    sel = select(FD_SETSIZE,&set,NULL,NULL,&timeout);
    // ... 后续事件处理逻辑保持不变
}

内容的提问来源于stack exchange，提问作者Apurva Swiðhun