Repository navigation
documentation on Stream.write misses that callback does not ensure that data written to process.stdout/.stderr is flushed #3670
Description
var empty = new Buffer(0)
process.stdout.write(empty, function() {
process.stderr.write(empty, function() {
process.exit(code);
});
});doesn't reliable ensure that a consumer of node.js will get all data (yes - it is a PIPE, not a FILE !!).
Activity
minesworld commentedon Nov 5, 2015
Oh - and to be a bit bitchy - either this or #3669 and related must be open.
I would suggest to open the other ones again as just fixing the docs would mean that node.js is unusable for implementing cli tools.
Fishrock123 commentedon Nov 5, 2015
@minesworld please don't open duplicates, we can re-open issues if necessary. :)
The "fix" is #3170, i.e. fix the docs.
process.exit()causes Node to terminate immediately, ignoring that data potentially hasn't been written places. The docs forprocess.exit()could probably be more clear.You don't have to use
.exit()to set an exit code -- you can just setprocess.exitCode. If you thenreturnsuch that nothing else is being done, node will exit more gracefully.The exact reason that it doesn't get written has something to do with chunked writes far lower down, probably near the OS layer. I'm not sure if this is actually properly fixable in libuv, see #1771 (comment) and libuv/libuv#428 -- ideally it's up to your application. In this case it means not immediately terminating the process on write.
@minesworld I haven't seen this happen for not-chunked writes before, perhaps that has to do with exiting in the cllback. Could you try wrapping the
process.exit()inprocess.nextTick(), and if that doesn't work,setImmediate(), and seeing if that works?Another option would be a
process.exitGracefully(), although you may be able to write that in an npm module.bnoordhuis commentedon Nov 5, 2015
Can I suggest we close this bug report? It's a known issue with several open bug reports. This one doesn't add anything new.
Fishrock123 commentedon Nov 5, 2015
@bnoordhuis maybe we should add this to the
known issuespart of the release notes given how many times it has come up... cc @nodejs/releasebnoordhuis commentedon Nov 5, 2015
Good idea.
minesworld commentedon Nov 7, 2015
Do node.js a favour by:
Putting it into known issues would be a just "OK" solution. But writing it into the docs gives it the prominent place it deserves. Because this behaviour is totally against the docs.
It doesn't matter that you shouldn't call process.exit(), the code before should have ensured that all data to stdio is flushed. Also sometimes it isn't possible to not call process.exit().
I've looked at the node and libuv code but didn't get my head around it yet. Here are some suggestions which might help:
minesworld commentedon Nov 7, 2015
I just want to express my thanks for NOT closing this issue and thinking about re-opening other issues again.
This here shouldn't have happened at all as I was the n person who experienced it and "wasted" a lot of time.
But better late then never.
For all of us out there using node.js a bit "different" - in my case its a ssh2 client - having these informations is really really crucial as it might affect the design phase etc.
Thats why I urge to put it into the docs...
minesworld commentedon Nov 7, 2015
If there is nobody to want to change the docs, let me know - I will fork it and do it for you.
At the moment I'm a bit under stress getting my ssh2 client working reliable as my current workaround to wait a bit for the data to be flushed before process.exit() needs some more work (as expected...)
Fishrock123 commentedon Nov 9, 2015
What's an example? I can't think of one unless your program is written such that you'd need to exit immediately to prevent other async calls for some reason.
@minesworld most of us a pretty busy and definitely wouldn't mind that. :)
minesworld commentedon Nov 9, 2015
@Fishrock123 when you haven't control over what other libraries are keeping in the background running...
I will fork node.js and update the docs ...
At the moment I'm using a workaround by listening on a pipe before process.stdout/.stderr to end and then wait 10 seconds before calling process.exit(). Its ugly and only 99,99% reliable and a waste of time if nothing big was written firsthand... but at least its working better than not using it.
minesworld commentedon Nov 11, 2015
Created a pull request: #3772
Hope that letting Node.js ending itself really ensures that all data to process.stdout/.stderr is flushed...
Trott commentedon Jun 6, 2016
I think this can be closed because all the relevant activity seems to be at #6456 and this issue has been dormant for nearly 7 months. Feel free to re-open (or comment asking that it be re-opened) if you disagree.