在Linux内核升级之后，我们注意到了命名pipe道的变化。 使用来自http://www.linuxjournal.com/content/using-named-pipes-fifos-bash的脚本，我们能够复制这个问题。 脚本工作
Linux TEST05 3.13.0-55-generic #94-Ubuntu SMP Thu Jun 18 00:27:10 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux 但是请继续
Linux TEST01 3.13.0-65-generic #106-Ubuntu SMP Fri Oct 2 22:08:27 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
命名pipe道的工作方式似乎有所不同。 那是有意的还是不是？
我们将这两个脚本捕获为pipe_reader.sh：
#!/bin/bash pipe=/tmp/testpipe trap "rm -f $pipe" EXIT if [[ ! -p $pipe ]]; then mkfifo $pipe fi while true do if read line <$pipe; then if [[ "$line" == 'quit' ]]; then break fi echo $line fi done echo "Reader exiting"
和pipe_writer.sh：
#!/bin/bash pipe=/tmp/testpipe if [[ ! -p $pipe ]]; then echo "Reader not running" exit 1 fi if [[ "$1" ]]; then echo "$1" >$pipe else echo "Hello from $$" >$pipe fi
有没有修复？
编辑：
我们正在自己的terminal中运行每个脚本。 他们认为写作者脚本从不存在，读者脚本从不显示正常的“Hello from …”输出。 我们在两个内核版本下都以相同的方式执行它们，所以这不是一次运行一个脚本或其他任何程序差异的问题。
我没有足够的名声写评论，所以写作答案。
你是什么意思挂？ 在其他terminal执行pipe_reader.sh和pipe_writer.sh会发生什么？
另外，在执行这两个脚本之后，命令是什么：
ls -al /proc/$(pgrep pipe_reader.sh)/fd
显示？
也许你已经跑了几个.pipe_reader脚本，所以只有第一个接收pipe_writer输出？ 确保
ps aux | grep pipe_reader | grep -v grep | wc -l
返回1
从我所了解的3.13.0-55和3.13.0-65都是相同的内核（3.13）与分发提供商的一些修补程序/补丁。 这种升级不太可能会改变pipe道function。 我相信打破这样的function将会被内核开发者所诟病。
还有其他事情正在发生。