process: `process.stdin` getter sets `O_NONBLOCK` flag in open file description #42826

0x2b3bfa0 · 2022-04-22T16:32:00Z

Version

v18.0.0

Platform

Linux codespaces-151d18 5.4.0-1074-azure #77~18.04.1-Ubuntu SMP Wed Mar 30 15:36:02 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Subsystem

process

What steps will reproduce the bug?

`TTY`

$ node -e 'process.stdin; require("fs").readSync(0, Buffer.alloc(1))'

`PIPE`

$ cat | node -e 'process.stdin; require("fs").readSync(0, Buffer.alloc(1))'

How often does it reproduce? Is there a required condition?

Consistently reproducible by making use of the process.stdin getter.

What is the expected behavior?

Read a single byte from the standard input and exit gracefully.¹

What do you see instead?

node:internal/fs/utils:345
    throw err;
    ^

Error: EAGAIN: resource temporarily unavailable, read
    at Object.readSync (node:fs:727:3)
    at [eval]:1:30
    at Script.runInThisContext (node:vm:129:12)
    at Object.runInThisContext (node:vm:305:38)
    at node:internal/process/execution:76:19
    at [eval]-wrapper:6:22
    at evalScript (node:internal/process/execution:75:60)
    at node:internal/main/eval_string:27:3 {
  errno: -35,
  syscall: 'read',
  code: 'EAGAIN'
}

Node.js v18.0.0

Additional information

The mere fact of accessing process.stdin causes libuv to set the O_NONBLOCK flag in the open file description, altering the behavior of fs.readSync(0, buffer) and throwing EAGAIN if there isn't enough data to be read.

Awareness

It looks like the behavior of that getter doing “things” is well–known internally, and several tests make use of this “feature”

node/test/parallel/test-child-process-stdin-ipc.js

Lines 29 to 30 in bde889b

    
           // Just reference stdin, it should start it 
        
           process.stdin; // eslint-disable-line no-unused-expressions

node/test/parallel/test-stdin-from-file-spawn.js

Lines 27 to 28 in bde889b

    
           // Reference the object to invoke the getter 
        
           process.stdin;

node/test/parallel/test-stdin-hang.js

Lines 25 to 30 in bde889b

    
           // This test *only* verifies that invoking the stdin getter does not 
        
           // cause node to hang indefinitely. 
        
           // If it does, then the test-runner will nuke it. 
        
           // invoke the getter. 
        
           process.stdin; // eslint-disable-line no-unused-expressions

Details

node/lib/internal/bootstrap/switches/is_main_thread.js

Lines 16 to 22 in 7319419

    
           function defineStream(name, getter) { 
        
             ObjectDefineProperty(process, name, { 
        
               configurable: true, 
        
               enumerable: true, 
        
               get: getter 
        
             }); 
        
           }

node/lib/internal/bootstrap/switches/is_main_thread.js

Line 25 in 7319419

defineStream('stdin', getStdin);

node/lib/internal/bootstrap/switches/is_main_thread.js

Line 175 in 7319419

function getStdin() {

node/lib/internal/bootstrap/switches/is_main_thread.js

Line 179 in 7319419

switch (guessHandleType(fd)) {

CASE `TTY`

node/lib/internal/bootstrap/switches/is_main_thread.js

Lines 180 to 184 in 7319419

    
           case 'TTY': { 
        
             const tty = require('tty'); 
        
             stdin = new tty.ReadStream(fd); 
        
             break; 
        
           }

node/lib/tty.js

Line 47 in 7319419

function ReadStream(fd, options) {

node/lib/tty.js

Line 54 in 7319419

const tty = new TTY(fd, ctx);

node/lib/tty.js

Line 31 in 7319419

const { TTY, isTTY } = internalBinding('tty_wrap');

node/src/tty_wrap.cc

Lines 140 to 143 in 1c4df35

    
           TTYWrap::TTYWrap(Environment* env, 
        
                            Local<Object> object, 
        
                            int fd, 
        
                            int* init_err)

node/src/tty_wrap.cc

Line 148 in 1c4df35

*init_err = uv_tty_init(env->event_loop(), &handle_, fd, 0);

node/deps/uv/src/unix/tty.c

Line 123 in 1c4df35

int uv_tty_init(uv_loop_t* loop, uv_tty_t* tty, int fd, int unused) {

node/deps/uv/src/unix/tty.c

Line 204 in c61870c

uv__nonblock(fd, 1);

CASE `PIPE`

node/lib/internal/bootstrap/switches/is_main_thread.js

Lines 192 to 194 in 7319419

    
           case 'PIPE': 
        
           case 'TCP': { 
        
             const net = require('net');

node/lib/internal/bootstrap/switches/is_main_thread.js

Lines 208 to 209 in 7319419

    
           stdin = new net.Socket({ 
        
             fd: fd,

node/lib/net.js

Line 291 in 7319419

function Socket(options) {

node/lib/net.js

Lines 356 to 358 in 7319419

    
           this._handle = createHandle(fd, false); 
        
           err = this._handle.open(fd);

node/lib/net.js

Line 143 in 7319419

function createHandle(fd, is_server) {

node/lib/net.js

Lines 146 to 150 in 7319419

    
           if (type === 'PIPE') { 
        
             return new Pipe( 
        
               is_server ? PipeConstants.SERVER : PipeConstants.SOCKET 
        
             ); 
        
           }

node/lib/net.js

Lines 63 to 67 in 7319419

    
           const { 
        
             Pipe, 
        
             PipeConnectWrap, 
        
             constants: PipeConstants 
        
           } = internalBinding('pipe_wrap');

node/src/pipe_wrap.cc

Lines 154 to 157 in 7319419

    
           PipeWrap::PipeWrap(Environment* env, 
        
                              Local<Object> object, 
        
                              ProviderType provider, 
        
                              bool ipc)

node/src/pipe_wrap.cc

Line 208 in 7319419

void PipeWrap::Open(const FunctionCallbackInfo<Value>& args) {

node/src/pipe_wrap.cc

Line 217 in 7319419

int err = uv_pipe_open(&wrap->handle_, fd);

node/deps/uv/src/unix/pipe.c

Line 137 in 7319419

int uv_pipe_open(uv_pipe_t* handle, uv_file fd) {

node/deps/uv/src/unix/pipe.c

Line 153 in 7319419

err = uv__nonblock(fd, 1);

bnoordhuis · 2022-04-23T09:43:04Z

What you're describing is expected behavior; node has basically always behaved that way, at least since the libuv switchover in the v0.5 days, and probably before that.

That said, instead of putting the file descriptor into non-blocking mode, libuv could use sendmsg() and recvmsg() with the MSG_DONTWAIT flag - assuming all supported platforms support it.

0x2b3bfa0 · 2022-04-23T15:14:42Z

Updated #42826 (comment), happens also on pipes.

bnoordhuis · 2022-04-27T21:09:12Z

Turns out sendmsg/recvmsg don't work on enough file descriptor types for my suggestion to be feasible. The current situation is probably as good as it gets.

gireeshpunathil · 2022-04-28T02:18:50Z

thinking aloud: non-blocking behaviour of the standard streams and pipes make sense; but should the sync readers absorb EAGAIN and retry, instead of throwing? alternatively document the fact (that synchronous operations on non-blocking descriptors may throw based on the descriptor's current ability to respond to the request)?

bnoordhuis · 2022-04-28T11:30:56Z

should the sync readers absorb EAGAIN and retry, instead of throwing?

No, because that effectively turns the operation into a busy loop. uv_fs_read() could block on poll(2) until the file descriptor becomes ready but that:

feels like solving the problem in the wrong place
doesn't necessarily work for all file descriptors types (can still get EAGAIN)
interacts poorly with uv_tty_t I/O on the event loop thread (indeterminate which reader gets what) but the thing OP wants to do is prone to that anyway

uv_tty_t handles could do blocking I/O on a separate thread. Libuv already does that on macOS because tty file descriptors don't work with kqueue(2) (facepalm, Apple) but it's a heavy weight solution and adds more failure modes like "can't spawn thread".

document the fact that synchronous operations on non-blocking descriptors may throw

Sure, but that's like documenting water is wet.

gireeshpunathil · 2022-04-28T12:37:45Z

thanks @bnoordhuis

No, because that effectively turns the operation into a busy loop.

https://nodejs.org/api/fs.html#synchronous-example already warns about implications of using sync variant as blocking the event loop for a period of time till the operation complete. But of course, agree that busy loop is not a good idea.

Sure, but that's like documenting water is wet.

This one I am finding it difficult to relate. At the system programming level, an I/O call on a non-blocking , non-ready descriptor throwing may be well understood, but at the Node.js API level where things are abstracted, this behaviour cannot be implied, and is not specified anywhere in the docs?

bnoordhuis · 2022-04-28T12:51:32Z

OP's example is fs.readSync(0, buf). When you work at that level of abstraction, you're probably well aware of the difference between blocking and non-blocking I/O.

The surprise seems to be that stdio fds in node are sometimes blocking, sometimes non-blocking. I agree that's something worth documenting.

bnoordhuis · 2022-12-29T10:25:30Z

I'm going to close this out. If anyone still wants to send a documentation pull request, please do.

0x2b3bfa0 mentioned this issue Apr 22, 2022

src/pipe-args.js hangs when cml is called from child_process.exec on macOS iterative/cml#982

Closed

bnoordhuis mentioned this issue Apr 23, 2022

Use MSG_DONTWAIT (instead of O_NONBLOCK) for tty fds? libuv/libuv#3602

Closed

casperdcl mentioned this issue May 11, 2022

fix cml publish stdin pipe iterative/cml#1000

Closed

Artur- mentioned this issue Nov 28, 2022

chore: Upgrade test runner plugins vaadin/flow#15102

Closed

bnoordhuis closed this as not planned Won't fix, can't repro, duplicate, stale Dec 29, 2022

0x2b3bfa0 mentioned this issue Dec 30, 2022

Investigate buffering issues on GitHub runners iterative/cml#1301

Open

adob mentioned this issue Feb 9, 2023

cmd/go,os: EAGAIN when writing to stdout/stderr during test golang/go#58408

Open

nferch mentioned this issue Apr 9, 2024

[agent] file logging fails with EAGAIN dxos/dxos#6227

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

process: `process.stdin` getter sets `O_NONBLOCK` flag in open file description #42826

process: `process.stdin` getter sets `O_NONBLOCK` flag in open file description #42826

0x2b3bfa0 commented Apr 22, 2022 •

edited

0x2b3bfa0 commented Apr 22, 2022 •

edited

bnoordhuis commented Apr 23, 2022

0x2b3bfa0 commented Apr 23, 2022 •

edited

bnoordhuis commented Apr 27, 2022

gireeshpunathil commented Apr 28, 2022

bnoordhuis commented Apr 28, 2022

gireeshpunathil commented Apr 28, 2022

bnoordhuis commented Apr 28, 2022

bnoordhuis commented Dec 29, 2022

process: process.stdin getter sets O_NONBLOCK flag in open file description #42826

process: process.stdin getter sets O_NONBLOCK flag in open file description #42826

Comments

0x2b3bfa0 commented Apr 22, 2022 • edited

Version

Platform

Subsystem

What steps will reproduce the bug?

TTY

PIPE

How often does it reproduce? Is there a required condition?

What is the expected behavior?

What do you see instead?

Additional information

Awareness

Related

Footnotes

0x2b3bfa0 commented Apr 22, 2022 • edited

Details

CASE TTY

CASE PIPE

bnoordhuis commented Apr 23, 2022

0x2b3bfa0 commented Apr 23, 2022 • edited

bnoordhuis commented Apr 27, 2022

gireeshpunathil commented Apr 28, 2022

bnoordhuis commented Apr 28, 2022

gireeshpunathil commented Apr 28, 2022

bnoordhuis commented Apr 28, 2022

bnoordhuis commented Dec 29, 2022

process: `process.stdin` getter sets `O_NONBLOCK` flag in open file description #42826

process: `process.stdin` getter sets `O_NONBLOCK` flag in open file description #42826

0x2b3bfa0 commented Apr 22, 2022 •

edited

`TTY`

`PIPE`

0x2b3bfa0 commented Apr 22, 2022 •

edited

CASE `TTY`

CASE `PIPE`

0x2b3bfa0 commented Apr 23, 2022 •

edited