-
Notifications
You must be signed in to change notification settings - Fork 29.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EPIPE errors thrown when piping to a closed stream #947
Comments
Perhaps 'node' could have a parameter added that would suppress closed pipe errors on stdout, almost as a cmdlet mode specifier. |
Related: #831. |
Doesn't seem to be limited to
A single call works though:
|
I'm not sure if this can help, but I've just seen exactly the same error displayed (on the console) from within a Koa application I'm developing:
Unfortunately I have no idea what caused it or how to replicate it – but also with so little information shown, no means of investigating it... (I'm not doing any piping or working with streams directly myself). This is on io.js v1.6.4, Koa v0.19.1. I can give further details of packages I'm using if it might help anyone. |
+1 for this issue. Just ran into it as well. Makes it impossible to create command line utilities that compose in the unix style. |
The problem is that, in the We don't currently expose a way for a program to check that the FD is still open ( User code can sidestep some of the badness by doing something like: blackholeEPIPE(process.stderr)
blackholeEPIPE(process.stdout)
function blackholeEPIPE(stream) {
stream.on('error', onerror)
function onerror(err) {
if (err.code === 'EPIPE') {
stream._write = noopWrite
stream._writev = noopWritev
stream._read = noopRead
return stream.removeListener('error', onerror)
}
if (EE.listenerCount(stream, 'error') === 1) {
stream.removeListener('error', onerror)
stream.emit('error', err)
}
}
}
function noopWrite(chunk, enc, cb) {
cb()
}
function noopRead() {
this.push('')
}
function noopWritev(chunks, cb) {
cb()
} |
Out of curiosity, how is this handled in other languages? I've never encountered this type of issue before. If checking before writing is error-prone, would it be possible to wrap some try/catch logic around the write to handle the error when it happens? |
- recent version of node.js throws EPIPE error when piped process does not read all data, see nodejs/node#947
This commit adds tests for several known issues. Refs: nodejs#1901 Refs: nodejs#728 Refs: nodejs#4778 Refs: nodejs#947 Refs: nodejs#2734 PR-URL: nodejs#5653 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
Fixes: nodejs#831 Fixes: nodejs#947 Ref: nodejs#9470
Requesting reopen, because this clearly still happens:
Or is there an alternative solution that I missed, which this was closed in favour of? |
@anko #9744 was deemed semver-major, so your example will work in Node 8 upwards, which is expected to be released in 2 weeks – there’s an RC available here: https://nodejs.org/download/rc/v8.0.0-rc.0/ If you’re using |
@addaleax I see. Thank you! ✨ |
@bozzmob Can you share any code that might be relevant? |
@bozzmob My earlier example that failed in Node 7 works in Node 8:
|
This error happens to me when streaming video with https://github.com/phoboslab/jsmpeg . It happens after a while when clients are connecting. I was using NodeJS 4.7.2. Now upgraded to 8.8.1 and error still exists.
|
@Dacesilian Could you post some code to reproduce that, ideally a minimal example? |
Sorry, I can't, because it's not my application and I don't understand it :( |
same error as @Dacesilian here |
If you are using Jsmpeg library like me. you can add code socket.on('error', function(e){ I have tested it. The server runs ok. |
I've also opened a related issue in the nodejs/node-v0.x-archive#9279 repo about this. The
error message from iojs is slightly different, but just as unhelpful in this situation.
For the sake of convenience, the rest of this post is verbatim what the issue
under the node repo had, with the minor change in error message accounted
for.
So this issue seems to have been around for quite some time. The problem
probably affects all instances where things are piped into closed streams, but a
very common example that comes up in practice is piping the output of a node
program to something else.
Let's use this as a simple (albeit contrived) example:
When piping to something that won't consume the entirety of the stream, the
program crashes in a very unhelpful way:
Categorizing this as an error in the first place is a little strange. While I
can appreciate that trying to write to a closed stream is an error in theory,
it seems really odd to crash like this when not paging through everything on
stdout.
Treating stdout as a special case may be a bit much to ask, but at the
very least, there should be some improvements to the error messaging here. The
example I gave was just using
iojs -e
, but even with a proper file, no usefulstacktrace or messaging is provided. Maybe add something like:
Warning: Attempting to pipe to a closed stream (foo.js:10:12)
?I discovered this as I was piping the output of a CLI program I'd written to
less
. When paging all the way to the bottom, no errors would be logged, butexiting less before paging all the way through would consistently have the EPIPE
error written to stderr.
Right now, there are a few workarounds.
Users can just redirect stderr to
/dev/null
like so:or use the epipebomb module.
Neither approach is ideal.
The text was updated successfully, but these errors were encountered: