node.exe via WSL fails with EINVAL on uv_pipe_open

[simonbuchan]

There are a few earlier reports on uv_pipe_open, but they seem to be about a "unknown system error" in linux node.

This has been happening in my old WSL for a few months now, at least, but I believe it was working as of CU. I wasn't too concerned since I had some cruft built up in my setup, and I didn't see any other reports, but it's still happening with the new Windows Store Ubuntu install.

Not too concerned, since you can always have a cmd.exe window up, but it is a pain when doing a windows yarn install (linux yarn install doesn't creating working windows bin stubs, but vice-versa does)

• Your Windows build number: (Type ver at a Windows Command Prompt)
  Microsoft Windows [Version 10.0.16241.1001]

• What you're doing and what's happening: (Copy&paste specific commands and their output, or include screen shots)

Any attempt to run node.exe (I'm using v6.11.1) from WSL fails:

$  node.exe
net.js:145
    this._handle.open(options.fd);
                 ^

Error: EINVAL: invalid argument, uv_pipe_open
    at Error (native)
    at new Socket (net.js:145:18)
    at process.getStdin [as stdin] (internal/process/stdio.js:70:19)
    at startup (bootstrap_node.js:177:18)
    at bootstrap_node.js:509:3

Very similar error if it doesn't need to open stdin:

$ node.exe -p 123
net.js:145
    this._handle.open(options.fd);
                 ^

Error: EINVAL: invalid argument, uv_pipe_open
    at Error (native)
    at new Socket (net.js:145:18)
    at createWritableStdioStream (internal/process/stdio.js:156:16)
    at process.getStdout [as stdout] (internal/process/stdio.js:10:14)
    at console.js:100:37
    at NativeModule.compile (bootstrap_node.js:492:7)
    at Function.NativeModule.require (bootstrap_node.js:433:18)
    at get (bootstrap_node.js:254:34)
    at evalScript (bootstrap_node.js:354:30)
    at run (bootstrap_node.js:122:11)

Same issue when running cmd.exe (which works), then running node.exe.

• What's wrong / what should be happening instead:

Should still work, obviously 🐱‍🐉

• Strace of the failing command, if applicable: (If <cmd> is failing, then run strace -o strace.txt -ff <cmd>, and post the strace.txt output here)

Pretty boring, since it's interop:

execve("/mnt/c/Program Files/nodejs/node.exe", ["node.exe"], [/* 22 vars */]) = 0
brk(NULL)                               = 0x7fffea3ab000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbb64fa0000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=19068, ...}) = 0
mmap(NULL, 19068, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fbb64faa000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\t\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1868984, ...}) = 0
mmap(NULL, 3971488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fbb64830000
mprotect(0x7fbb649f0000, 2097152, PROT_NONE) = 0
mmap(0x7fbb64bf0000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1c0000) = 0x7fbb64bf0000
mmap(0x7fbb64bf6000, 14752, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fbb64bf6000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbb64f90000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbb64f80000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbb64f70000
arch_prctl(ARCH_SET_FS, 0x7fbb64f80700) = 0
mprotect(0x7fbb64bf0000, 16384, PROT_READ) = 0
mprotect(0x7fbb6520b000, 4096, PROT_READ) = 0
mprotect(0x7fbb64e25000, 4096, PROT_READ) = 0
munmap(0x7fbb64faa000, 19068)           = 0
getpid()                                = 9495
brk(NULL)                               = 0x7fffea3ab000
brk(0x7fffea3cc000)                     = 0x7fffea3cc000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=1668976, ...}) = 0
mmap(NULL, 1668976, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fbb64c8d000
close(3)                                = 0
getcwd("/mnt/c/code/splinter", 4096)    = 21
open("/dev/lxssclient", O_RDWR)         = 3
ioctl(3, _IOC(0, 0x00, 0x2f, 0x22), 0x7ffff189a7b0) = 0
open("/mnt/c/Program Files/nodejs/node.exe", O_RDONLY) = 5
ioctl(3, _IOC(0, 0x00, 0x3f, 0x22), 0x7ffff189a660) = 0
close(5)                                = 0
open("/mnt/c/code/splinter", O_RDONLY)  = 5
ioctl(3, _IOC(0, 0x00, 0x3f, 0x22), 0x7ffff189a660) = 0
close(5)                                = 0
ioctl(4, _IOC(0, 0x00, 0x97, 0x22), 0x7ffff189a710) = 0
ioctl(4, _IOC(0, 0x00, 0xb7, 0x22), 0x7ffff189a708) = 0
ioctl(4, _IOC(0, 0x00, 0xb7, 0x22), 0x7ffff189a708) = 0
ioctl(4, _IOC(0, 0x00, 0xb7, 0x22), 0x7ffff189a708) = 0
write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0002\0\0\0\0\0\0\0"..., 171) = 171
read(4, "\0\0\0\0\0\0\0\0001\0\0\0\0\0\0\0", 16) = 16
ioctl(4, _IOC(0, 0x00, 0x9b, 0x22), 0x7ffff189a7a8) = 0
write(4, "\0\0\0\0\0\0\0\0001\0\0\0\0\0\0\0", 16) = 16
ioctl(5, _IOC(0, 0x00, 0xbf, 0x22), 0x7ffff189a7a0) = 0
close(3)                                = 0
close(4)                                = 0
close(5)                                = 0
exit_group(1)                           = ?
+++ exited with 1 +++

See our contributing instructions for assistance.

[benhillis]

Does node.exe support input / output being redirected? For example do you hit the same issue when running node.exe > out.txt form within a cmd window?

[simonbuchan]

In case it wasn't clear, node is https://nodejs.org/ node :)

C:\Users\simon>node -p 123 > node.out

C:\Users\simon>type node.out
123

Doesn't seem that redirecting stdin does anything useful in a quick test...

[simonbuchan]

Using stdin:

C:\Users\simon>echo "Hello, world!" | node -e "process.stdin.pipe(process.stdout)"
"Hello, world!"

[skylize]

I have some more related stack traces in Issue #2467 from trying to run apm.exe, which is now marked as duplicate of this issue.

[therealkenc]

@benhillis - Someone else at MSFT is feeling your pain. I thought I would try and be clever and make a point, but node.exe doesn't work with the new fangled native Windows 10 OpenSSH either. This is with sshd running on port 22 on the win32 side, and all the public key accoutrements. On the WSL side:

ken@DESKTOP-4UTIQSF:~$ ssh ken@localhost systeminfo.exe | grep -e "^OS Version"
OS Version:                10.0.17063 N/A Build 17063
ken@DESKTOP-4UTIQSF:~$ ssh ken@localhost node.exe --version
v9.4.0
ken@DESKTOP-4UTIQSF:~$ ssh ken@localhost node.exe
<falls on face and hangs>

So the question is, which team fixes it first? 😉

[therealkenc]

Actually it looks like they are a little closer and just have a buffer/flush problem:

ken@DESKTOP-4UTIQSF:~$ ssh ken@localhost node.exe
console.log("sup?");     <---- I hit enter and Ctrl-D here
sup?

The Ctrl-D was a lucky guess.

[benhillis]

@therealkenc - I'm currently working on a change that should fix this.

[marchaos]

Hey Ben. Any update on the progress of this?