NodeJS Error: spawn EACCES (different variants of this error)

[tracy-codes]

Hey all, I've been having this issue for a few weeks now with NodeJS with modules that specifically need to spawn child processes. The two main packages I've enconutered this with are create-react-app's "test" command and Zeit's Now CLI within WSL. Below is the information necessary for the issues I'm experiencing.

Please fill out the below information:

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

• What you're doing and what's happening: (Copy&paste the full set of specific command-line steps necessary to reproduce the behavior, and their output. Include screen shots if that helps demonstrate the problem.)

Reproduce the Zeit Now CLI Error

1. npm i -g now
2. now login
3. Login with your now credentials
4. git clone https://github.com/tracy-codes/tracycodes-portfolio.git (project files used to push to now)
5. cd tracycodes-portfolio
6. now

Expected output is as follows:

$ now
now
> Deploying ~\dev\tracycodes\tracycodes-portfolio under tracycodes
> Using project my-portfolio
https://my-portfolio-cg6rbcv31.now.sh
┌ **        Ready               [414ms]
├── src/main.js
├── src/img/favicon.png
├── index.html
├── README.md
├── _redirects
├── src/style.css
├── about.html
└── coming-soon.html
> Success! Deployment ready [4s]

Actual output on WSL:

$ now
> Deploying /c/Users/tracy/dev/tracycodes/tracycodes-portfolio under tracycodes
> Using project my-portfolio
> Synced 5 files (8.87KB) [2s]
> https://my-portfolio-8zxgcamfp.now.sh [v2] [1s]
> Error! An unexpected error occurred!
  Error: spawn xsel EACCES
    at Process.ChildProcess._handle.onexit (internal/child_process.js:229:19)
    at onErrorNT (internal/child_process.js:406:16)
    at process._tickCallback (internal/process/next_tick.js:63:19) Error: spawn xsel EACCES
    at Process.ChildProcess._handle.onexit (internal/child_process.js:229:19)
    at onErrorNT (internal/child_process.js:406:16)
    at process._tickCallback (internal/process/next_tick.js:63:19)

Reproduce create-react-app's test error

1. npm i -g create-react-app
2. create-react-app test
3. cd test
4. yarn run test

Expected output:

$ yarn run test
yarn run v1.13.0
$ react-scripts test
No tests found related to files changed since last commit.

Actual output in WSL:

$ yarn run test
yarn run v1.13.0
$ react-scripts test
Determining test suites to run...events.js:173
      throw er; // Unhandled 'error' event
      ^

Error: spawn hg EACCES
    at Process.ChildProcess._handle.onexit (internal/child_process.js:246:19)
    at onErrorNT (internal/child_process.js:421:16)
    at processTicksAndRejections (internal/process/next_tick.js:76:17)
Emitted 'error' event at:
    at Process.ChildProcess._handle.onexit (internal/child_process.js:252:12)
    at onErrorNT (internal/child_process.js:421:16)
    at processTicksAndRejections (internal/process/next_tick.js:76:17)
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

• What's wrong / what should be happening instead:
  I'm encountering multiple different "spawn EACCES" errors for Node modules that seem to require spawning child processes.

I've tested this with Jest with --watch, Create-React-App's "test" command, and the Now CLI from Zeit. For Create-React-App's "test" and Jest's --watch, they both output the "Error: spawn hg EACCES" with the above trace. I've tried the following to resolve the issue on my own:

1. Completely remove NPM, Node, and Yarn and reinstall from scratch
2. Install watchman (recommended by FB and seems to fix the issue on some Macs)
3. Set permissions to 777 for global node_modules and local modules in the projects' directories
4. Uninstalled/Deleted WSL and did a clean install, installed Node/NPM/Yarn first, then went through the reproduction steps above and still encountered the errors

Please let me know if there's anything else I can provide to add value to this issue report, and I hope someone can help me find a resolution for this!

I've reported this issue to Zeit's Now CLI team and they haven't ever encountered this error before:
#1902

[craigloewen-msft]

Hi @tracy-codes !

Could you please run an strace on the failing commands? Instructions on how to do so are here.

It'll help us get a better picture of what's going on!

[tracy-codes]

Hi @tracy-codes !

Could you please run an strace on the failing commands? Instructions on how to do so are here.

It'll help us get a better picture of what's going on!

Hi @mscraigloewen! Thank you so much for taking the time to investigate this issue. The following two gists are for the Now and the create-react-app test straces:

1. Now Strace Output
2. create-react-app test strace output files (this generated 198 strace files, these are the ones >1000kb):
   • https://gist.github.com/tracy-codes/cdec11a0410b264f55dacb8b0b649801
   • https://gist.github.com/tracy-codes/2952a3f58dda62a3c1ecc60bf6442596\
   • https://gist.github.com/tracy-codes/909062c6481d356f0f0a290863b7f6a7
   • https://gist.github.com/tracy-codes/f388c023607a53f663611f02532b7954
   • https://gist.github.com/tracy-codes/cca19eb84d6569eefdaeb740b71d3926

[craigloewen-msft]

No problem :) We'll take a look and post any updates as they become available.

[tracy-codes]

@mscraigloewen Sounds good! Thank you ❤

[therealkenc]

Well, the only EACCES in there is:

execve("/c/Users/Administrator/AppData/Local/Microsoft/WindowsApps/xsel", ["xsel", "--clipboard", "--input"], 0x4286910 /* 30 vars */) = -1 EACCES (Permission denied)

Which would strangely enough make this variation #3833 (comment).

What does echo $PATH return for you right before you run now? Try:

$ export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$ # ... do node things

That might still fail for other reasons if now really requires xsel(1). It might not. (Wouldn't know. There is no repro and I've never really been a huge Tangerine Dream fan.)

If now really does require xsel(1) for reasons, then do sudo apt install xsel after rationalizing your $PATH.

[tracy-codes]

@therealkenc Running that path cmd and doing my node things seems to have worked! I think this issue is solved by the export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin command. Thank you so much!

[craigloewen-msft]

I'll close out this issue. Thank you for the fix @therealkenc , and thanks for filing the issue @tracy-codes !

[therealkenc]

Thank you for the fix @therealkenc

YW. Glad you're up and running.

But just for clarification, the underlying bug in both this issue and #3833 remains. I have no horse in that race mind you, and am never one to turn down a closed issue#.

If /c/Users/Administrator/AppData/Local/Microsoft/WindowsApps/xsel or /mnt/c/WINDOWS/system32/config/systemprofile/.dnx/bin/help can't be executed, then they shouldn't have been marked as executable. This is a diverge. I can't tell for sure if that counts as dupe #2779 or not (maybe not). But I can say the WSL ABI is coughing up dirents that claim they can be executed when they can't. Because, otherwise now wouldn't have tried to execve() the thing, only to die trying. Rationalizing the $PATH to something sane avoids the issue, but doesn't address the underlying problem. Just sayin'.

[craigloewen-msft]

Ah I see! I'll re-open the issue so we can track that the underlying cause isn't fixed.

[therealkenc]

Alright I looked a little closer since I went and opened my mouth. I had said quoth "the WSL ABI is coughing up dirents that claim they can be executed when they can't". That isn't the case. zsh and presumably now (whatever now is) is blindly appending names to the $PATH components. This makes sense in Real Linux™ because putting a component in your $PATH that you don't have permission to access is just plain "user error".

In WSL (contrast the real thing) we have the added snag of paths where the underlying Windows user doesn't have permission. This is harmless in Windows because Windows software is written with the assumption that can happen. Having nonsensical components in one's Window's %PATH% is "normal". But Linux software isn't written with that assumption.

The repro over in #3833 is maybe better because .../Microsoft/WindowsApps/xsel here looks to be something third party that the OP installed. Over there, .../.dnx/bin is in WSL's $PATH if you've installed Visual Studio 2015. [I gather. Actually I wouldn't know a DNX from the hole in the ground either but I think it gets put in the Windows %PATH% along with the kitchen sink that is MSVS.] I guess I got "lucky" because if I didn't have MSVS 2015 I wouldn't have had the path component, I wouldn't have been able to reproduce #3833's problem either.

$ echo "$PATH" | tr ':' '\n' | grep WINDOWS/system32
/mnt/c/WINDOWS/system32
/mnt/c/WINDOWS/system32/config/systemprofile/.dnx/bin

But that path isn't accessible, because the Windows user (me) doesn't have permissions to that path. That's going to be the case for the OP's xsel too.

Fix is going to be to launder path components from being imported when the Windows user doesn't have permission to that component. Basically, interop is imposing a "user error" on WSL, because it is putting components in the $PATH that can't ever be accessed. The ABI strictly speaking is correct.