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

[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.

[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

[manshu]

events.js:141
throw er; // Unhandled 'error' event
^

Error: write EPIPE
at Object.exports._errnoException (util.js:874:11)
at exports._exceptionWithHostPort (util.js:897:20)
at WriteWrap.afterWrite (net.js:763:14)

I am having this error while testing in PHPSpec, any takers ?