nodejs sometimes leaves stdout/stderr in non-blocking mode
- Version: v8.3.0
-
Platform:
Linux 19083a5259e3 4.4.0-1022-aws #31-Ubuntu SMP Tue Jun 27 11:27:55 UTC 2017 x86_64 GNU/Linux
- Subsystem: Unknown
node appears to leave stdout/stderr in non-blocking mode in certain cases, which can cause errors in other programs which assume these are in blocking mode. I'm not certain if this is a bug or not, but am just trying to understand this behavior better.
I'm having trouble finding authoritative information about non-blocking mode and whether it's "correct" for programs to assume that they'll be given stdout/stderr in blocking mode, but it does appear that a lot of programs aren't able to handle having stdout/stderr in blocking mode (Python being a notable case). It's also strange that node only appears to do this in specific cases (e.g. in Docker without a TTY).
Reproduction
I haven't yet been able to find a way to reproduce this without Docker. I've created a simple test repo that prints the status of the blocking flag before and after running nodejs at https://github.com/chriskuehl/nodejs-nonblocking-repro. It shows that the blocking flag on stdout/stderr changes after nodejs is run.
Alternatively, a reproduction using Docker looks like this:
-
docker run -i node:latest bash
to enter a shell in the container (don't use-t
; it doesn't work if using a tty) -
python -c 'print "x" * 100000'
inside the container to show that Python can print a lot of text without failing -
nodejs -e 'console.log(1+1)'
inside the container. After running this command, stdout/stderr have been changed to non-blocking mode. -
python -c 'print "x" * 100000'
inside the container, which should crash after printing some text (you should see a traceback somewhere, it may be at the top or interlaced in the middle of the printed text)
In Python 2, the traceback error is IOError: [Errno 11] Resource temporarily unavailable
. In Python 3, it's a little more helpful: BlockingIOError: [Errno 11] write could not complete without blocking
.