Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Consistent EPIPE error writing to stdout when pipe has disconnected (SIGPIPE related?) #3211

Closed
mhart opened this Issue · 8 comments

2 participants

@mhart

This error seems to happen consistently when any Node program is writing to stdout through a pipe that has disconnected (SIGPIPE related?)

Here's a very simple example:

$ cat test.js 
for (var i = 0; i < 100; i++) console.log(i)
$ node test.js | head -1
0

node.js:201
        throw e; // process.nextTick error, or 'error' event on first tick
              ^
Error: write EPIPE
    at errnoException (net.js:670:11)
    at Object.afterWrite [as oncomplete] (net.js:503:19)
$

Happens on Node v0.6.16, Mac OS X 10.7.3 and Node v0.6.15, Ubuntu 12.04

Is this expected behaviour? Does one need to handle SIGPIPE in some special way?

I've never seen this in other languages, eg:

$ cat test.sh
for i in {0..100}; do echo $i; done
$ bash test.sh | head -1
0
$
@mhart

May also be related to #2286?

@mhart

OK, so adding a SIGPIPE handler that just exits the process seems to eliminate this.

process.on('SIGPIPE', process.exit)
for (var i = 0; i < 100; i++) console.log(i)
$ node test.js | head -1
0
$

Still... is this intended behaviour?

@mhart

Hmmm, the plots thickens. Trying to exit on SIGPIPE doesn't fix the problem if reading from stdin (perhaps the handler is not caught early enough?):

process.on('SIGPIPE', process.exit)
process.stdin.resume()
process.stdin.on('data', function(data) { process.stdout.write(data) })
$ for i in {0..100000}; do echo $i; done | node test.js | tail -1
100000

Works as expected, but:

$ for i in {0..100000}; do echo $i; done | node test.js | head -1
0

node.js:201
        throw e; // process.nextTick error, or 'error' event on first tick
              ^
Error: write EPIPE
    at errnoException (net.js:670:11)
    at Object.afterWrite [as oncomplete] (net.js:503:19)

Also should be noted that adding a check for process.stdout.writable before attempting to write appears to make no difference - the error still occurs

@bnoordhuis

Is this expected behaviour? Does one need to handle SIGPIPE in some special way?

EPIPE is an expected error. Handle it like you handle other runtime errors, e.g. by attaching an 'error' event listener to process.stdout.

@bnoordhuis bnoordhuis closed this
@mhart

Really? So you can't just write to stdout and expect it to work if you happen to pipe it through head or similar?

That's... bizarre.

I really think you should reconsider this for a second. This error really should be ignored as it was in v0.1.94 and v0.1.6 (see the Node ChangeLog)

How can you explain the difference in behaviour when I listen for SIGPIPE too? The EPIPE error "disappears" in one case, but not in another.

And is there any documentation that EPIPE is an expected error? I couldn't find it anywhere. Everything I can find seems to suggest that this error shouldn't happen in normal circumstances.

It seems that this was fixed in earlier versions of Node too (cf #2286) and http://comments.gmane.org/gmane.comp.lang.javascript.nodejs/5524

@bnoordhuis

This error really should be ignored as it was in v0.1.94 and v0.1.6

Read the thread you link to carefully - it's about ignoring SIGPIPE. SIGPIPE != EPIPE. The first is a signal, the second an error code that syscalls return.

How can you explain the difference in behaviour when I listen for SIGPIPE

Node by default ignores SIGPIPE signals - unless you install your own handler.

@mhart

OK - thanks for the explanation.

I guess I just struggled to find any documentation on this being expected behaviour (and any documentation on how to deal with it).

@mhart

Created an npm package to deal with this in case anyone else runs into it: https://github.com/mhart/epipebomb

@ryan-williams ryan-williams referenced this issue from a commit in hammerlab/grafana-spark-dashboards
@ryan-williams ryan-williams make parse-dashboard-json robust to EPIPE errors 417478a
@kipraske kipraske referenced this issue in kipraske/web-brogue
Closed

Server Crashes on EPIPE write #30

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.