Bug: "Launching server using runtime node failed. Error: spawn node ENOENT" #1596
Comments
|
Very hard to say why the node runtime is not found. Why are you using your own? VS Code ships with a node runtime that is suitable for most use cases. Can you try to remove the settings |
|
This started to happen to me randomly too, had never seen it before using the extension for years. Removing |
|
@dbaeumer the use case to use our own runtime is of course that all our ESLint tests run with constructs available in the Node.js version we use? Or am I missing something? |
|
In which setting file do you make that change. If you are running for example in WSL you need to change that setting in the Remote settings |
|
We run with remote SSH, and set the setting in the workspace settings. Would it work if we set them in the remote SSH settings?
We have had them set in the workspace settings for a long time, does that mean it never worked? Why is the setting not greyed out like it is in the user settings then (I can see reasons for this, but asking as a sanity question)?
But our end goal is this: We are a team of developers that always install Node on our local machines, all using the same version (we enforce it via nvm). We want to make sure all of us use the same version of the node binary, due to that ESLint construct (functions etc.) usage depends on version of Node.js. Is there no way then to achieve this than to ask all developers to set this themselves in the remote SHH config? |
|
I'm running in macOS, and changing the config via |
|
@thernstig you can also set it in the workspace settings (e.g..vscode/settings.json). When you run in a remote SSH setup the ESLint extension run on the remote machine, hence the settings of the remote machine apply and not the local user settings. This is how VS Code works. @rdsedmundo I just tested this locally and using |
|
@dbaeumer of that I am aware. What I wondered was if setting it in workspace settings did not work, considering you said that for WSL I needed to set it there. But from your text above it seems you confirmed setting it in But then if it is allowed to set it in the workspace settings when running with remote SSH, I would guess there is a newly introduced bug somewhere. I never seen this before for years, but it started to happen recently probably during the last VS Code or ESLint extension upgrade. As we mention this is very seldom and happens only sometimes. So some kind of race condition seems at play here. Is there anything I can do, once this happened, to gather some logs? Without restarting anything? |
|
@dbaeumer this is super weird, I haven't really changed anything but from yesterday to today it started working again... I'll let you know if it breaks again and try to check for the process info as you suggested. |
|
@thernstig you could enable tracing in the ESLint server using |
|
@dbaeumer will do. Will report back with the traces if I get the fault again. To summarize all these lengthy discussions: |
|
@dbaeumer have the same issue recently. May be it related to https://github.com/lukechilds/zsh-nvm (need to investigate a bit), because "eslint.runtime": "MY_HOME/.nvm/versions/node/v19.8.1/bin/node" (from 'which node' in integrated terminal) works fine. Stack trace with 'node': |
|
The ESLint server is relying on the fact that node is available on the PATH or you provided an absolute path to it. If |
|
Sure, I just provided my temporary issue as an illustration, because it was fixed by proper nvm setup. BTW, may be it's possible to improve error message a bit? "Error: spawn node ENOENT" -> 'Error: spawn node ENOENT, PATH=xxx, cwd=yyy', or something like that. Now it's a black box, and debugging (especially for people not so familiar with OS / shell) is really hard. |
|
@dbaeumer I was able to reproduce this consistently now, for my case it happens when I log out of my computer and check the option Reopen windows when logging back in, and then log in again. Even if I perform "VSCode: Reload window" several times it still doesn't work, however if I fully kill the process (CMD+Q) and re-open it, then the config works again. This used to work in the past as I had mentioned above, because I have been using this extension for years. I'd imagine though this is more likely to be either a regression in VSCode itself, or in the newer versions of MacOS that changed something? I have macOS 13.2.1. |
|
This failure is done for me in VS Code in Windows, working remotely against an SSH machine. So it is not macOS specific. As mentioned before, this has never been a problem before but starting occurring a few releases ago. |
|
I tried to reproduce this in a local SSH setup but wasn't able to do so. I actually thing that this is not caused by the ESLint extension itself but may be some change in the remote SSH extension and how it sets up the environment. @thernstig what happens if you use an absolute path to the node executable. Does it happen as well? |
|
@dbaeumer I have not tested, but that is not feasible for me as we use @dbaeumer if you want to keep the issue list clean, I am fine with closing this until I can actually prove exactly what happens. I have added |
|
Thanks for investigating further. I will still keep the issue open |
|
@dbaeumer I just got the issue again. I have set Restarting VS Code does not help. If I open the terminal I see: ~/code/projectA (jsdoc)> node -v
v18.14.2Using the command Disabling the ESLint plugin, reloading VS Code, and enabling it again (without reloading) does make it work again. |
|
I looked through the code again and what happens is the following:
@roblourens do you have any idea why @thernstig is it important for you to use a custom runtime. If you are happy with node |
|
@dbaeumer it is important, as some ESLint features depend on what ECMAScript version is used, which correlates with the Node.js version. Here is an idea why Basically what happens is that the ~/code/projectA (TEST)> which node
/home/userA/.local/share/nvm/v18.14.2/bin/node
~/code/projectA (TEST)> cd ..
direnv: unloading
~/code> which node
~/code [1]> cd projectA/
direnv: loading ~/code/projectA/.envrc
direnv: using nvm
direnv: using node
direnv: Successfully loaded NodeJS v18.14.2 (via .nvmrc), from prefix (/home/userA/.local/share/nvm/v18.14.2)
direnv: export +ANSIBLE_CONFIG +CPATH +DOCKER_BUILDKIT +KUBECONFIG +LD_LIBRARY_PATH +LIBRARY_PATH +MANPATH +PKG_CONFIG_PATH +PLAYWRIGHT_BROWSERS_PATH ~PATH
~/code/projectA (TEST)> which node
/home/userA/.local/share/nvm/v18.14.2/bin/node
~/code/projectA (TEST)>Is it that |
Which "node" is this supposed to be? Do we add it to PATH? |
|
Actually that would be something @roblourens needs to answer. The extension host sees the environment of the remote server which I don't know in which shell context it is started. |
|
Sorry I don't fully understand the situation, but in other places I'm aware of when an extension wants to spawn its own node process, I think that we spawn |
|
I think it's need to add some debug code into extension itself and dump PATH / env / 'which node' right before spawn call. |
|
@roblourens The eslint code calls |
|
@koshic good idea. I will log the PATH when starting the server fails. |
|
Now I understand, thanks. If you grab the log from the Remote-SSH output channel, you can see the environment the the vscode server was started in. That's the environment that the remote server gets and that is inherited by the remote EH. You called out the fish shell- actually we usually fail to connect at all when fish is the default shell for ssh connections microsoft/vscode-remote-release#2509. But it seems likely that some configuration script you have isn't getting run in this case so node is left out of your PATH. |
|
I will close the issue. For the request of using a default installed Node version see #1727. |
|
@dbaeumer I have not seen this issue in a long time now, but I will surely revert back if it happens again. Thanks for your patience and kind support. |
|
@dbaeumer I ran into this again: [Info - 1:49:05 PM] ESLint server is starting.
[Info - 1:49:05 PM] ESLint server stopped.
[Error - 1:49:05 PM] ESLint client: couldn't create connection to server.
Launching server using runtime node failed. Error: spawn node ENOENT
[Error - 1:49:05 PM] Starting the server failed.
Launching server using runtime node failed. Error: spawn node ENOENT
[Info - 1:49:05 PM] PATH environment variable is: /home/userA/.vscode-server/bin/903b1e9d8990623e3d7da1df3d33db3e42d80eda/bin/remote-cli:/home/userA/.pyenv/shims:/home/userA/.pyenv/bin:/home/userA/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/binI am fairly certain I know the cause of this. We are using https://github.com/direnv/direnv-vscode. Basically it loads the environment and augmenst the PATH variable with e.g. the path to the Is this a race condition where something loads things into the environment, and this extension does not pick it up because it starts "too early". Can/should this extension look for environment changes and reload or restart the ESLint server when found? $PATH[1]: |/home/userA/code/projectA/bob|
$PATH[2]: |/home/userA/code/projectA/.venv/bin|
$PATH[3]: |/home/userA/code/projectA/node_modules/.bin|
$PATH[4]: |/home/userA/.local/share/nvm/v20.10.0/bin|
$PATH[5]: |/home/userA/code/projectA/devenv_temp/bin|
$PATH[6]: |/home/userA/code/projectA/scripts/dev|
$PATH[7]: |/home/userA/code/projectA/tests/brand1_e2e|
$PATH[8]: |/home/userA/.pyenv/shims|
$PATH[9]: |/home/userA/.pyenv/bin|
$PATH[10]: |/home/userA/.local/bin|
$PATH[11]: |/usr/local/sbin|
$PATH[12]: |/usr/local/bin|
$PATH[13]: |/usr/sbin|
$PATH[14]: |/usr/bin|
$PATH[15]: |/sbin|
$PATH[16]: |/bin|
$PATH[17]: |/usr/games|
$PATH[18]: |/usr/local/games|
$PATH[19]: |/snap/bin|
$PATH: originally inherited as |/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin| |
|
There are no events for environment changes so there is nothing I can listen for. I do see the problem however I can't think about a proper solution except of restarting the server manually when you see the issue. The eslint extension activates on A hack that could be investigated is to check if the direnv extension is installed and wait for their activation to be finished before starting the server. |
|
Would you be interested in looking into a PR for such a hack? |
|
@dbaeumer possibly, though I personally feel wary about such a solution where an extension (vscode-eslint) depends/checks for one other specific extension (direnv-vscode), as there could be other extensions altering the environment. Maybe it is an intermediate solution and a post should be made on https://github.com/microsoft/vscode/? I am not sure how to phrase such an issue there though, or if it would even get attention. What I have seen is that restarting the ESLint server does not help either. What would that indicate? |
The ESLint server inherits the environment from the extension host (e.g. the process running all extensions). If a restart doesn't help that means that the extension host doesn't have an updated environment either. I actually don't know how the direnv extension is altering the envirnment to understand why it is not reflected in the extension host. |
|
@dbaeumer I think I have some investigation to do then. To understand if direnvv-vscode should change its code, or if the extension host from VS Code needs an update or a new event to handle someone trying to update the environment (could be a security issue of course). Hmm. All open for advice. |
|
One idea to find this out is using a dummy extension and run it under the debugger and inspect process.env. |
|
@dbaeumer thanks for the idea, a bit over my knowledge level as I never authorened an , but I will let this simmer a bit more. I suppose the idea of posting this as a feature request at the vscode repo, for a new event, is not a good idea then? |
|
@thernstig I think we need to first understand what exactly |
|
hi there,
we inject the environment by modifying @thernstig we also log which changes we apply to the environment, in the Output panel look for as for startup order, we try to activate direnv as early as possible ( |
|
@dbaeumer with the info from @mkhl above, I can only see two options:
Any more ideas? |
|
I actually do (2). When I launch the server I has Node API to do so which takes the current env into consideration. The other workaround I see is to add a setting that makes this extension wait for the activation of the env extension. |
|
Well, then I am stumped. @dbaeumer I do not understand how the extension can take the latest env on commands, since the original problem described even happens when executing the command |
|
I don't understand it either. Every time the server starts I freshly read the environment from the process environment here: https://github.com/microsoft/vscode-languageserver-node/blob/691fd5d3fabeed5ed8ff9c3608f2d306cb07717e/client/src/node/main.ts#L248 What you could do is may be to patch that method in JS and |
|
@dbaeumer is that code doing what 2) above shows as in ocamllabs/vscode-ocaml-platform#1322? It says it does it on every command, not every server start. It is possible I misunderstood you of course. @mkhl are you comfortable enough reading this extensions code to see something? I am unfortunately not wellversed in VS Code extension authoring. |
|
@thernstig the eslint server is a separate process with its own environment. What I ensure is that I inject the CURRENT extension host environment into that process when I launch the server. So if direnv has changed the env and the server is re-started it should see that env. |
|
@dbaeumer then it is possible the problem for restarting is another one, as it does not want to do that: [Error - 9:33:46 AM] Restarting client failed
Error: Client is not running and can't be stopped. It's current state is: startFailed
at b.shutdown (/home/userA/.vscode-server/extensions/dbaeumer.vscode-eslint-2.4.4/client/out/extension.js:1:104688)
at b.stop (/home/userA/.vscode-server/extensions/dbaeumer.vscode-eslint-2.4.4/client/out/extension.js:1:104269)
at b.stop (/home/userA/.vscode-server/extensions/dbaeumer.vscode-eslint-2.4.4/client/out/extension.js:1:270385)
at b.restart (/home/userA/.vscode-server/extensions/dbaeumer.vscode-eslint-2.4.4/client/out/extension.js:1:270252)
at /home/userA/.vscode-server/extensions/dbaeumer.vscode-eslint-2.4.4/client/out/extension.js:1:387592
at u.h (/home/userA/.vscode-server/cli/servers/Stable-863d2581ecda6849923a2118d93a088b0745d9d6/server/out/vs/workbench/api/node/extensionHostProcess.js:150:184839)
at u.$executeContributedCommand (/home/userA/.vscode-server/cli/servers/Stable-863d2581ecda6849923a2118d93a088b0745d9d6/server/out/vs/workbench/api/node/extensionHostProcess.js:150:185699)
at s.S (/home/userA/.vscode-server/cli/servers/Stable-863d2581ecda6849923a2118d93a088b0745d9d6/server/out/vs/workbench/api/node/extensionHostProcess.js:147:5519)
at s.Q (/home/userA/.vscode-server/cli/servers/Stable-863d2581ecda6849923a2118d93a088b0745d9d6/server/out/vs/workbench/api/node/extensionHostProcess.js:147:5285)
at s.M (/home/userA/.vscode-server/cli/servers/Stable-863d2581ecda6849923a2118d93a088b0745d9d6/server/out/vs/workbench/api/node/extensionHostProcess.js:147:4375)
at s.L (/home/userA/.vscode-server/cli/servers/Stable-863d2581ecda6849923a2118d93a088b0745d9d6/server/out/vs/workbench/api/node/extensionHostProcess.js:147:3454)
at p.value (/home/userA/.vscode-server/cli/servers/Stable-863d2581ecda6849923a2118d93a088b0745d9d6/server/out/vs/workbench/api/node/extensionHostProcess.js:147:2241)
at n.y (/home/userA/.vscode-server/cli/servers/Stable-863d2581ecda6849923a2118d93a088b0745d9d6/server/out/vs/workbench/api/node/extensionHostProcess.js:80:1902)
at n.fire (/home/userA/.vscode-server/cli/servers/Stable-863d2581ecda6849923a2118d93a088b0745d9d6/server/out/vs/workbench/api/node/extensionHostProcess.js:80:2119)
at r.fire (/home/userA/.vscode-server/cli/servers/Stable-863d2581ecda6849923a2118d93a088b0745d9d6/server/out/vs/workbench/api/node/extensionHostProcess.js:105:14091)
at p.value (/home/userA/.vscode-server/cli/servers/Stable-863d2581ecda6849923a2118d93a088b0745d9d6/server/out/vs/workbench/api/node/extensionHostProcess.js:173:8050)
at n.y (/home/userA/.vscode-server/cli/servers/Stable-863d2581ecda6849923a2118d93a088b0745d9d6/server/out/vs/workbench/api/node/extensionHostProcess.js:80:1902)
at n.fire (/home/userA/.vscode-server/cli/servers/Stable-863d2581ecda6849923a2118d93a088b0745d9d6/server/out/vs/workbench/api/node/extensionHostProcess.js:80:2119)
at r.fire (/home/userA/.vscode-server/cli/servers/Stable-863d2581ecda6849923a2118d93a088b0745d9d6/server/out/vs/workbench/api/node/extensionHostProcess.js:105:14091)
at u.z (/home/userA/.vscode-server/cli/servers/Stable-863d2581ecda6849923a2118d93a088b0745d9d6/server/out/vs/workbench/api/node/extensionHostProcess.js:105:17156)
at p.value (/home/userA/.vscode-server/cli/servers/Stable-863d2581ecda6849923a2118d93a088b0745d9d6/server/out/vs/workbench/api/node/extensionHostProcess.js:105:15608)
at n.y (/home/userA/.vscode-server/cli/servers/Stable-863d2581ecda6849923a2118d93a088b0745d9d6/server/out/vs/workbench/api/node/extensionHostProcess.js:80:1902)
at n.fire (/home/userA/.vscode-server/cli/servers/Stable-863d2581ecda6849923a2118d93a088b0745d9d6/server/out/vs/workbench/api/node/extensionHostProcess.js:80:2119)
at p.acceptChunk (/home/userA/.vscode-server/cli/servers/Stable-863d2581ecda6849923a2118d93a088b0745d9d6/server/out/vs/workbench/api/node/extensionHostProcess.js:105:11865)
at /home/userA/.vscode-server/cli/servers/Stable-863d2581ecda6849923a2118d93a088b0745d9d6/server/out/vs/workbench/api/node/extensionHostProcess.js:105:11152
at Socket.y (/home/userA/.vscode-server/cli/servers/Stable-863d2581ecda6849923a2118d93a088b0745d9d6/server/out/vs/workbench/api/node/extensionHostProcess.js:170:13198)
at Socket.emit (node:events:514:28)
at addChunk (node:internal/streams/readable:324:12)
at readableAddChunk (node:internal/streams/readable:297:9)
at Readable.push (node:internal/streams/readable:234:10)
at Pipe.onStreamRead (node:internal/stream_base_commons:190:23) |
|
Is there anything more in the Output channel. Looks like a previous restart has failed. |
|
@dbaeumer it is the same output as in the original post, which contains the entire output. The previous start failed due to node not being found. Then restarting the client does not fail. It should have if it re-reads the env as the extension host env should contain the proper |
|
@thernstig have you checked the If I understand correctly you're observing the problem in remote SSH workspaces. Does it also occur in local workspaces? |
|
@mkhl I have not received the problem again and have not been able to check. I will report back once I see it. It is very intermittent. It only occurs on remote SSH workspaces. I never use local workspaces, and since it is intermittent it is hard to reproduce. |
This explains why the restart doesn't work. The restart fails because the original start fails since it is using the same client object to not loose any internal client state when restarting the server. What we could do is to use a new client in the restart case if a previous start failed. I opened #1808 |
|
@dbaeumer that will most likely at least solve the restart part yay :) Is there a chance that if a start fails, you do a I am still curious if you think I should open a VS Code issue to ask for an extension API regarding environment changes? You are far better of to judge if that would make sense or not than I am. |
Honestly I think such an API request will not be implemented due to the fact the NodeJS doesn't provide it. It would a require poll/compare implementation which is never good. |
Type: Bug
At times when starting VS Code the ESLint server is stopped. It happens intermittently and quite seldom. Using the command
ESLint: Restart ESLint Serverdoes not help. Here is the output from the OUTPUT panel.Using the terminal,
nodedoes exist:I have set
"eslint.runtime": "node",both in the user and workspace settings.json files.I have no idea what could be wrong. I have been using the ESLint extension for years, but this started to happen more recently within the past few months.
Extension version: 2.2.6
VS Code version: Code 1.74.3 (97dec172d3256f8ca4bfb2143f3f76b503ca0534, 2023-01-09T16:59:02.252Z)
OS version: Windows_NT x64 10.0.19044
Modes:
Sandboxed: No
Remote OS version: Linux x64 5.4.0-137-generic
System Info
canvas_oop_rasterization: disabled_off
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
skia_renderer: enabled_on
video_decode: enabled
video_encode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled
webgpu: disabled_off
A/B Experiments
The text was updated successfully, but these errors were encountered: