NodeJS Error: spawn EACCES (different variants of this error) #3886
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:
Reproduce the Zeit Now CLI Error
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
$ 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.
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:
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:
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:
Well, the only
That might still fail for other reasons if
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#.
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.
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
The repro over in #3833 is maybe better because
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
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