关于管道的几个奇葩问题

1，进程运行一段时间后，发现进程异常，gdb发现进程阻塞在printf！阻塞在printf，是的

经过查看 ls /proc/pid/fd 发现文件描述符0,1,2都指向了一个管道。管道？0,1,2,不应该指向终端、或则/dev/null嘛，怎么会指向管道。
经过艰苦的排查，发现是由于进程是由于另一个机子上进程通过ssh2协议远程执行指令启动的，这里先描述一下他的过程：

A:                                             B:
                            ssh协议
sshd服务端 <---------------------- intall a.out  (具体中间的建立回话和鉴权省略)
        |                                                                  
        |
 启动客户端sshd:root/notty
        |
        |
 客户端执行system调用
        |
        |
 运行本地的安装脚本
  启动进程a.out

那么问题来了，我们假设ssh的客户端进程 sshd:root/notty 为进程s，进程s调用fork 、exec，假设fork 的子进程为进程m，
在启动a.out过程中，进程s会创建3个管道，管道另一端分别对应子进程m的0,1,2句柄，然后exec将子进程m替换为a.out，因此最终a.out的0,1,2，句柄分别对应一个管道的一端，而且进程s在执行完exec，关掉了进程m的0,1,2中的0,2对应的管道的那端，目前可用的管道只剩下了进程m的1,句柄对应的管道。如下图

进程s                                  进程m (a.out)
5->pipe[1111]      --X--      0->pipe[1111] 
6->pipe[2222]      -----      1->pipe[2222] 
7->pipe[3333]      --X--      2->pipe[3333] 

那么在a.out的所有标准输出都写到了管道pipe[2222] 中，如果对端没有读，当管道写满后，就会阻塞，就出现了开所说始的现象！

2，进程运行一段时间后，system执行某个脚本阻塞，system没有返回？
如果出现上面的情况，任何原因导致的标准输出重定向到的管道阻塞，那么任何标准输出的函数都会被阻塞，如printf，以及system时的echo等，如果是这种情况，也就会导致system调用的阻塞未返回。