What makes a Unix process die with Broken pipe?

简介: What makes a Unix process die with Broken pipe? up vote6down votefavorite Here are some options I thought of, not sure which is the right one. a) The

Here are some options I thought of, not sure which is the right one.

a) There was an I/O error reading from the pipe.

b) The process writing to the other end of the pipe died with a failure.

c) All processes who could write to the pipe have closed it.

d) The write buffer of the pipe is full.

e) The peer has closed the other direction of the duplex pipe.

f) Writing failed because there are no processes which could read from the pipe.

g) A system call returned the EPIPE error, and there was no error handler installed.

share improve this question
 
 
What's your question? Are you asking which of those is correct, or if there are any other things that can cause the broken pipe? –   EightBitTony  Jul 29 '13 at 15:15
 
@EightBitTony Which of these is correct –   siamii  Jul 29 '13 at 15:16

3 Answers

A process receives a SIGPIPE when it attempts to write to a pipe (named or not) or socket of type SOCK_STREAM that has no reader left.

It's generally wanted behaviour. A typical example is:

find . | head -n 1

You don't want find to keep on running once head has terminated (and then closed the only file descriptor open for reading on that pipe).

The yes command typically relies on that signal to terminate.

yes | some-command

Will write "y" until some-command terminates.

Note that it's not only when commands exit, it's when all the reader have closed their reading fd to the pipe. In:

yes | ( sleep 1; exec <&-; ps -fC yes)
      1 2       1        0

Their will be 1 (the subshell), then 2 (subshell + sleep), then 1 (subshell) then 0 fd reading from the pipe after the subshell explicitely closes its stdin, and that's when yes will receive a SIGPIPE.

Above, most shells use a pipe(2) while ksh93 uses a socketpair(2), but the behaviour is the same in that regard.

When a process ignores the SIGPIPE, the writing system call (generally write, but could be pwritesendsplice...) returns with a EPIPE error. So processes wanting to handle the broken pipe manually would typically ignore SIGPIPE and take action upon a EPIPE error.

share improve this answer
 

(f)

Writing failed because there are no processes which could read from the pipe.

Although unless you duplicate descriptors and fork, there can only be one process to start with: generally a pipe has one reader and one writer, and when one of them closes the connection, the pipe is defunct. If you are using a named pipe, you can can make multiple connections (in serial) with it, but each one represents a new pipe in this sense. So a "pipe" to a thread or process is synonymous with a file descriptor.

From man 7 pipe:

If all file descriptors referring to the read end of a pipe have been closed, then a write(2) will cause a SIGPIPE signal to be generated for the calling process. If the calling process is ignoring this signal, then write(2) fails with the error EPIPE.

So a "broken pipe" is to the writer what EOF is to the reader.

share improve this answer
 
4  
It's not always a mistake. The yes command relies on SIGPIPE to terminate, the head command generally causes SIGPIPEs to be sent. –   Stéphane Chazelas  Jul 29 '13 at 16:27

A broken pipe happens when the reading process exits before the writing process. So I would go with (f)

share improve this answer
 
 
There can be several processes reading or writing to a pipe, and the same process can be reading and writing. Also, it's not about exiting, it's about closing the file descriptor. –   Stéphane Chazelas  Jul 29 '13 at 16:26
目录
相关文章
|
Unix Perl Ubuntu
A Unix Utility You Should Know About: Pipe Viewer
Hi all. I'm starting yet another article series here.
782 0
|
7月前
|
缓存 网络协议 Unix
Linux(UNIX)五种网络I/O模型与IO多路复用
Linux(UNIX)五种网络I/O模型与IO多路复用
177 0
|
7月前
|
Unix Shell Linux
在Unix/Linux操作系统中,Shell脚本广泛用于自动化任务
在Unix/Linux操作系统中,Shell脚本广泛用于自动化任务
71 2
|
2天前
|
Unix Linux 编译器
UNIX/Linux 上的安装
UNIX/Linux 上的安装。
11 2
|
2月前
|
Unix 物联网 大数据
操作系统的演化与比较:从Unix到Linux
本文将探讨操作系统的历史发展,重点关注Unix和Linux两个主要的操作系统分支。通过分析它们的起源、设计哲学、技术特点以及在现代计算中的影响,我们可以更好地理解操作系统在计算机科学中的核心地位及其未来发展趋势。
|
4月前
|
Unix Linux 程序员
Unix:Linux的“逗趣祖师爷”与它的不凡传承
在科技长河中,Unix犹如一颗恒星,既是历史见证者也是未来的启发者。1969年,因程序员肯·汤普森想在他的PDP-7上玩“Space Travel”游戏,意外创造了Unix,以简洁优雅的代码改变了操作系统的世界。进入90年代,林纳斯·托瓦兹受Unix启发,开发了开源免费的Linux,像是Unix调皮的孙子,不仅继承其精髓还增添了开放共享的精神。Unix与Linux之间的传承,就像是智者与追蝶孩童的故事,充满了岁月的智慧与新生的活力,提醒我们科技传奇往往源于不起眼的小事。下次使用Linux时,不妨会心一笑吧!
58 0
|
4月前
|
开发框架 Unix Linux
LangChain 构建问题之在Unix/Linux系统上设置OpenAI API密钥如何解决
LangChain 构建问题之在Unix/Linux系统上设置OpenAI API密钥如何解决
56 0
|
7月前
|
Unix Shell Linux
在Linux和类Unix系统中,Shell提供了多种命令用于用户和权限管理
在Linux和类Unix系统中,Shell提供了多种命令用于用户和权限管理
78 4
|
Unix 大数据 Linux
【Linux is not Unix】Linux前言
【Linux is not Unix】Linux前言
|
7月前
|
Oracle Ubuntu Unix
Unix与Linux区别
Unix: Unix是一个操作系统家族的名称,最早由贝尔实验室(Bell Labs)的肖像电机公司(AT&T)开发。最早的Unix版本是在1969年创建的。 Linux: Linux是由芬兰计算机科学家Linus Torvalds在1991年创建的。它是作为一个免费、开放源代码的Unix克隆而开始的。
122 1
AI助理

阿里云 AI 助理已上线!

快来体验一下吧。