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?

[benhillis]

@marchaos - Still working through some changes, no ETA yet but hoping to get this fixed soon.

[131]

From nodejs/stdio.js I'll guess that WSL expose PIPEs file descriptor for stdin/stdout/stderr when spawning .exe, when they should have been forwarded as TTY/console (yet i guess, unix TTY & windows TTY interop is not an easy path).

For nodejs.exe, you can force STDIN, STDOUT & STDERR as real PIPEs so node_bootstrap (and your script) won't crash. node.exe foo.js > NUL 2>NUL < NUL

 Object.defineProperty(process, 'stdout', {
    configurable: true,
    enumerable: true,
    get: () => require('fs').createWriteStream('stdout'),
  });

  Object.defineProperty(process, 'stderr', {
    configurable: true,
    enumerable: true,
    get: () => require('fs').createWriteStream('stderr')
  });

const Console = global.console.Console;
var console = global.console = new Console(process.stdout, process.stderr);
console.log("foo");

[insert motivation picture for @benhillis here !]

[benhillis]

@131 - Thanks for the workaround, that will be useful for people until I get this fixed, hopefully soon!

[molokoloco]

+1 for this issue
For now i have Docker only working in WSL but NodeJS and MongoDB only working in PowerShell or Git-Bash, very annoying...

[therealkenc]

If it rains another weekend I am going to beat you to it, Ben. 😛

[aleksijohansson]

+1 for this issue! It seems to be causing an issue in Lando too.

[therealkenc]

A hundred rock star points for Ben (ed: and Mike!) getting this one in 17618. 💯

A few sentence hint about the technical details of the change would be fun; there is quite a lot of interest in working with ptys in Windows out there. I never did follow up on the win32 dropbear server experiment above despite plenty of rain.

[Strangely (?) I had to hack my registry to force skip-ahead builds; the Settings UI said it is still closed. Dunno if that's just me.]

[benhillis]

I don't deserve all the credit, shout-out to @zadjii-msft for his hard work. We are working out a way to formalize this functionality into a set of APIs.

[therealkenc]

We are working out a way to formalize this functionality into a set of APIs

You're probably way ahead of me, but you could do worse than ask Daniel on the VS Code team what he thinks it might look like. He lives and breathes this stuff on the consuming end.

That or, you know, don't change the win32 API at all and just sneak a few constants into the WDK here and there. DeviceIoControl with FSCTL_SET_MKNOD_POINT, TIOCGPTN, TIOCSPTLCK. You managed to talk them into AF_UNIX on win32 socket(), so I just assumed character-special files were on the way 🙃.

[simonbuchan]

We are working out a way to formalize this functionality into a set of APIs.

To be clear, this would mean supporting embedding a WSL or Win32 (e.g. cmd.exe) console that knows it's interactive, without any weird hidden console hacks? That sounds great!

[benhillis]

Fixed in 17618.

[lolmaus]

Fixed in 17618.

How do I apply this fix on Windows 10?

UPD: I'm on Insider Fast and I still see this issue.

[givanse]

I recently started to see this error. My system was working just fine for the last month though.

Windows 10 Pro fully updated as of 5/13/2018
Version 1709
OS Build 16299.431

This is the output:

~$ nvm use 9.11.1
net.js:266
    this._handle.open(fd);
                 ^

Error: EINVAL: invalid argument, uv_pipe_open
    at new Socket (net.js:266:18)
    at createWritableStdioStream (internal/process/stdio.js:169:16)
    at process.getStdout [as stdout] (internal/process/stdio.js:19:14)
    at console.js:419:19
    at NativeModule.compile (internal/bootstrap/loaders.js:209:7)
    at Function.NativeModule.require (internal/bootstrap/loaders.js:137:18)
    at setupGlobalConsole (internal/bootstrap/node.js:355:41)
    at startup (internal/bootstrap/node.js:75:7)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:575:3)
nvm is not compatible with the npm config "prefix" option: currently set to ""
Run `npm config delete prefix` or `nvm use --delete-prefix v9.11.1` to unset it.

[benhillis]

Mentioned earlier in the thread that this is fixed in build 17618.

[givanse]

TL;DR Bash was picking up nvm-windows, which tried to use Node Windows binaries.

I upgraded to 17666.1000 and I was still seeing:

Error: EINVAL: invalid argument, uv_pipe_open

I thought that starting from fresh maybe would help. So I deleted everything related to nvm and node. After that, the nvm command still worked. That is how I found that bash was also picking up nvm-windows.

whereis nvm
nvm: /mnt/c/Users/gaston/AppData/Roaming/nvm/nvm.exe

I uninstalled that and then installed regular nvm again. Everything worked from there.

[maldimirov]

I know the thread is closed, but I hope this helps someone in future. I am using WSL and for no obvious reason I got the same error:

net.js:210
    this._handle.open(options.fd);
                 ^

Error: EINVAL: invalid argument, uv_pipe_open
    at new Socket (net.js:210:18)
    at createWritableStdioStream (internal/process/stdio.js:164:16)
    at process.getStdout [as stdout] (internal/process/stdio.js:14:14)
    at console.js:249:38
    at NativeModule.compile (bootstrap_node.js:597:7)
    at Function.NativeModule.require (bootstrap_node.js:542:18)
    at setupGlobalConsole (bootstrap_node.js:311:41)
    at startup (bootstrap_node.js:71:7)
    at bootstrap_node.js:609:3

I am using nvm and just running nvm use <your_node_version> solved the issue for me.

[abrioy]

Here's a quick and dirty solution based on @131 answer, for those of us who still have this issue:

npm() { cmd.exe /C "npm $@ 2>&1 < NUL | cat" }

You can set it as an alias in your shell and have a mostly working npm in wsl.

[Almenon]

@abrioy Thanks for that function you're amazing!

Some small changes:

There should be a semicolon at the end of the line before the last curly bracket. Also $@ will cause problems when you pass in more than one argument.

For example, calling foo() { cmd.exe /C "echo $@ 2>&1 < NUL | cat" } with foo a b c will result in:

a" b "c

No idea why this happens, but if you use $* to get command line arguments as a string instead of an array it works.

working function:

npm() { cmd.exe /C "npm $* 2>&1 < NUL | cat"; }

[lucotmo]

hello, the solution for me was to uninstall nodejs.
sudo apt remove nodejs
then:

sudo apt install wget
wget -qO- https://raw.githubusercontent.com/creationix/nvm/v0.34.0/install.sh | bash
source ~/.profile

look at the current list of versions in nodejs

nvm ls-remote

Install the required or desired version
nvm install 10.15.3

And confirm that he used it
node -v

conclusion

everything happens due to the bad installation of nodejs without the npm corresponding to the version

[aleksijohansson]

@lucotmo I don't think that is related to this issue because you are installing node inside the WSL instead of running the node installed on Windows from WSL.

[singcl]

@lucotmo It works for me. Thanks guys.

[bdJohnson72]

I am seeing this same error on build Build 17763. It is happening when I try to combine commands from the Salesforce CLI plugin and redirect the stdout to a csv.

brooksdjohnson@DESKTOP-L4C7EFO:~$ sfdx force:data:soql:query -q 'SELECT FirstName, LastName FROM COntact Limit 20' -u uber > test.csv
net.js:268
    err = this._handle.open(fd);
                       ^

Error: EINVAL: invalid argument, uv_pipe_open
    at new Socket (net.js:268:24)
    at createWritableStdioStream (internal/process/stdio.js:191:18)
    at process.getStderr [as stderr] (internal/process/stdio.js:32:14)
    at console.js:455:19
    at NativeModule.compile (internal/bootstrap/loaders.js:364:7)
    at Function.NativeModule.require (internal/bootstrap/loaders.js:176:18)
    at setupGlobalConsole (internal/bootstrap/node.js:407:41)
    at startup (internal/bootstrap/node.js:142:7)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:622:3)

[CompSciMaj13]

My work windows laptop is unfortunately managed by my company so atm I cannot upgrade to the fix, BUT I was able to find a nice workaround. This will be best for those who cannot simply upgrade.

I just created an alias in WSL to call out the command through cmd.exe and included the NUL hack:

In my ~/.bashrc

I was running into this error when trying to run npx Cypress open

...
alias wnpx="cmd.exe /C 'npx $1 $2 > NUL 2>NUL < NUL'"

Therefore when in the WSL terminal (currently using wsltty), all I need to run is:
wnpx Cypress open
and it will open within Windows. The $1 and $2 are the parameters passed after wnpx.
Also, wnpx is just an arbitrary name I created. It can be anything you want to call it.

Doesn't seem to work out of VSC's WSL plugin's terminal...

Hopefully, this can help someone in a similar situation.

The sourced 131's hack above ☝️

[nacho-marin]

Just executed

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.35.3/install.sh | bash

in a "Ubuntu 18.04.3 LTS" in WSL 2 at Windows 10 version 1909 (build 18363.657).

The issue persists.

[liuliangsir]

Same issue here.

[goleary]

I ran into this issue after upgrading to WSL 2 with a Ubuntu distro.

After unregistering & reinstalling Ubuntu I managed to get it working.

[aleen42]

Finally, I solved the problem by using the following alias:

function npm {
    cmd.exe /C "npm $* 2>&1 < NUL"
}
export -f npm

[Lena123qwe]

I'm having trouble installing npm :")

npm WARN invalid config registry="regitry.npmjs.org" set in C:\Users\pazto\AppData\Roaming\npm\etc\npmrc npm WARN invalid config Must be full url with "http://" npm WARN invalid config registry="regitry.npmjs.org" set in C:\Users\pazto\AppData\Roaming\npm\etc\npmrc npm WARN invalid config Must be full url with "http://" [..................] / idealTree:firestore-import-export-master: sill idealTree buildDeps