Revisit hardcoded timeout for resolving shell environment blocking first window open

[Ben-WD]

Issue Type: Bug

I'm developing a Node.js webserver application with the following launch configuration:

{
    // Use IntelliSense to learn about possible Node.js debug attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch Program",
            "type": "node",
            "program": "${workspaceFolder}/dist/server.js",
            "request": "launch",
            "preLaunchTask": "npm: build"
        },
        {
            "type": "node",
            "request": "attach",
            "name": "Attach by Process ID",
            "processId": "${command:PickProcess}",
            "protocol": "inspector"
        }
    ]
}

This has been working perfectly until version 1.49 has been installed. Since then, I get the following error when launching the application:

Can't find Node.js binary "node": path does not exist. Make sure Node.js is installed and in your PATH, or set the "runtimeExecutable" in your launch.json

Output from echo $PATH:

/Users/ben/.rbenv/shims:/Users/ben/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/ben/Library/Android/sdk/platform-tools/

Out from which node:

/usr/local/bin/node

Of course I can add the argument runtimeExecutable to launch.json, but I think this should not be necessary.

VS Code version: Code 1.49.0 (e790b93, 2020-09-10T17:39:53.251Z)
OS version: Darwin x64 19.6.0

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz (12 x 2600)
GPU Status	2d_canvas: enabled flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on protected_video_decode: unavailable_off rasterization: enabled skia_renderer: disabled_off_ok video_decode: enabled webgl: enabled webgl2: enabled
Load (avg)	2, 2, 2
Memory (System)	16.00GB (0.02GB free)
Process Argv
Screen Reader	no
VM	0%

Extensions (13)

Extension	Author (truncated)	Version
angulardoc-vscode	Ang	6.1.3
vscode-eslint	dba	2.1.8
xml	Dot	2.5.1
EditorConfig	Edi	0.15.1
vscode-npm-script	eg2	0.3.13
prettier-vscode	esb	5.6.0
php-debug	fel	1.13.0
twig-language-2	mbl	0.9.2
debugger-for-chrome	msj	4.12.10
vscode-react-native	msj	0.17.0
vscode-jest	Ort	3.2.0
vscode-icons	vsc	10.2.0
markdown-all-in-one	yzh	3.3.0

[connor4312]

Where do you have your PATH configured in that way? If you launch VS Code from the shell (code -- with no existing running VS Code instance) it will inherit those variables, but if you launch it from the desktop app it might not have the same variables

You can see the PATH that VS Code has by running Developer: Toggle Developer Tools and entering process.env.PATH in the console.

[Ben-WD]

@connor4312 Output from Developer tools console:

process.env.PATH
"/Users/ben/.rbenv/shims:/Users/ben/bin:/usr/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Apple/usr/bin:/Users/ben/Library/Android/sdk/platform-tools/"

Since /usr/local/bin is in path, everything should be working. It has been working for month until 1.49 was installed automatically.

[qiulang]

I have the same problem after I upgraded to 1.49 !

Version: 1.49.0
Commit: e790b931385d72cf5669fcefc51cdf65990efa5d
Date: 2020-09-10T17:39:53.251Z
Electron: 9.2.1
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Darwin x64 19.6.0

I hit this error

If I changed runtimeExecutable I hit the following error

If I changed runtimeExecutable and runtimeArgs I hit the following error

[connor4312]

That's coming from your shell.

In js-debug to find Node we run which node or where node in the current environment. https://github.com/microsoft/vscode-js-debug/blob/8581c0bcda559b775d8666fb5765641c4118498b/src/common/pathUtils.ts#L15 Your observation that running npm directly does not find Node validates that the environment is wrong in the ext host.

As a workaround, you may be able to get things to work by setting console: integratedTerminal in your launch config along with the runtime executable, so that your program is run in a real shell.

@sandy081 / @isidorn did something change in 1.49 that would interfere with the environment that the extension host receives?

[qiulang]

Hi added console: integratedTerminal fixed the problem, but even more strange is that after I restarted vscode the problem goes away!

I didn't remember whether I restarted vscode yesterday but today that did fix the problem!

[liheeng]

I had same problem after upgrading to 1.49.0.

[adambiggs]

Same problem after upgrading to 1.49.0. Problem went away after downgrading to 1.48.2.

[sandy081]

Sorry, I have no idea. If it is extensionHost related pinging @alexdima

[alexdima]

Can someone impacted please try:

• open developer tools (Help > Toggle Developer Tools)
• in the console, evaluate process.env['PATH']. Is this the same $PATH as in your terminal?
• also evaluate process.env['DYLD_LIBRARY_PATH']

The only change that happened in this timeframe around the extension host process launching that I'm aware of is 1b5fbca which removes DYLD_LIBRARY_PATH from the environment because it was causing some crashes, but that should not impact the PATH env variable.

ping @joaomoreno

[sweettyler]

I got an error message right after launching vscode: We did not find "node" on your path, so can not enable auto-attach in your environment ... on Linux.

I am using the insider version and do an update everyday. I don't have this issue yesterday, so the problem must be caused by changes between the insider version "d1f267742169584db010716d92addf50d4cd8139" and "9e505675670d65138405321a60b0df4ddec28799".

Ref: #106938, which was marked(?!) as a "duplicate" of this one.

[sweettyler]

And in my case, installing the nightly version of JavaScript Debugger can make that error message gone (#106938).

Any explanation?

[connor4312]

I'm not sure how the debugger version is related to the issue, I haven't touched this area since the stable release. Curious whether using the nightly works for everyone, like @Ben-WD and @qiulang.

[vsellen]

Just updated and have what is likely a related problem. In my case I have the path to electron specified in launch.json:

           "type": "node",
           "request": "launch",
           "name": "Electron Player2",
           "runtimeExecutable": "~/workspace/electron_build/electron_x/dist/electron",
           "program": "${workspaceFolder}/app/main.js",
           "console":"integratedTerminal",
           "args": ["--playernum=player2"]
       },

Error message on launching debug states that the path does not exist:

This worked correctly before updating to 1.49.0. Hope this is useful.

Version: 1.49.0
Commit: e790b93
Date: 2020-09-10T13:20:50.359Z
Electron: 9.2.1
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Linux x64 4.15.0-112-generic

[connor4312]

That's not related, but does it work if you replace the tilde ~ with the complete path? We don't untildify those at the moment, and I know 'some things' fail with them.

[vsellen]

Thanks. Untildifying did make a difference. Now I am getting a permission denied error in the debug console and no popup dialog. I will try to track that down, but as you said this is not related to the issue above.

[qiulang]

@connor4312 After I restart vscode I don't have the problem any more. I tried to reproduce it but I can't

[greglnye]

Same problem here when platform is WSL but works fine when platform is Windows.

Version: 1.49.1 (user setup)
Commit: 58bb7b2
Date: 2020-09-16T23:27:51.792Z
Electron: 9.2.1
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Windows_NT x64 10.0.20170

Opened VS Code from WSL terminal ( code . ) and Launch Program

Received error message: Can't find Node.js binary "node": path does not exist. Make sure Node.js is installed and in your PATH, or set the "runtimeExecutable" in your launch.json

Output from: echo "$PATH" (in WSL: Ubuntu-20.04 terminal)
/home/greg/.asdf/shims:/home/greg/.asdf/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/c/Python38/Scripts/:/c/Python38/:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/WINDOWS/System32/WindowsPowerShell/v1.0/:/c/WINDOWS/System32/OpenSSH/:/c/Program Files/PowerShell/7/:/c/Program Files/dotnet/:/c/Program Files/Git/cmd:/c/Program Files/Docker/Docker/resources/bin:/c/ProgramData/DockerDesktop/version-bin:/c/Program Files/nodejs/:/c/ProgramData/chocolatey/bin:/c/Users/Greg/AppData/Local/Microsoft/WindowsApps:/c/Users/Greg/AppData/Local/Programs/Microsoft VS Code Insiders/bin:/c/Users/Greg/AppData/Roaming/npm:/c/Users/Greg/AppData/Local/Programs/Microsoft VS Code/bin:/snap/bin:/home/greg/.local/bin:/usr/local/go/bin:/home/greg/go/bin:/home/greg/dart-sass:/home/greg/.fzf/bin:/home/greg/.local/bin:/usr/local/go/bin:/home/greg/go/bin:/home/greg/dart-sass

Output from: which node (in WSL: Ubuntu-20.04 terminal)
/home/greg/.asdf/shims/node

Output from: process.env['PATH'] (in VS Code dev console)
C:\Python38\Scripts;C:\Python38;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0;C:\WINDOWS\System32\OpenSSH;C:\Program Files\PowerShell\7;C:\Program Files\dotnet;C:\Program Files\Git\cmd;C:\Program Files\Docker\Docker\resources\bin;C:\ProgramData\DockerDesktop\version-bin;C:\Program Files\nodejs;C:\ProgramData\chocolatey\bin;C:\Users\Greg\AppData\Local\Microsoft\WindowsApps;C:\Users\Greg\AppData\Local\Programs\Microsoft VS Code Insiders\bin;C:\Users\Greg\AppData\Roaming\npm;C:\Users\Greg\AppData\Local\Programs\Microsoft VS Code\bin

No WSL paths!

Works with work-around by adding:

"linux": {
        "runtimeExecutable": "/home/greg/.asdf/shims/node"
}

to launch.json

launch.json:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "type": "node",
            "request": "launch",
            "name": "Launch Program",
            "skipFiles": [
                "<node_internals>/**"
            ],
            "program": "${workspaceFolder}/app.js",
            "linux": {
                "runtimeExecutable": "/home/greg/.asdf/shims/node"
            }
        }
    ]
}

Also just to check, switched to Windows with Remote-WSL: Reopen Folder in Windows and Launch Program

No errors, works fine.

All above is reproducible.

[connor4312]

@greglnye do you add the .asdf shims to your path inside your .bashrc or similar file? If so, VS Code will only pick those up if you also launched the VS Code application from the shell--which is not possible in remote scenarios. You may be able to fix this by setting the shims path in your .profile instead. (my previous investigation into this: microsoft/vscode-js-debug#717)

[alexdima]

cc @aeschli who has recently looked into some environmental variable fixes for WSL.

[MatayoshiMariano]

Did same thing as @greglnye and @connor4312 said, set up runtimeExecutable to whatever path your node executable is.
Since i'm using nvm and on a macbook

"runtimeExecutable": "/Users/USERNAME/.nvm/versions/node/v8.10.0/bin/node"

[connor4312]

@MatayoshiMariano nvm is a known case where (in their default install) we won't always pick it up, because it's set in your .bashrc which isn't run by VS Code and won't be applied unless you launch code from the command line. See here microsoft/vscode-js-debug#717 (comment)

[gabgagnon]

I had the same problem. Many of you restarted VScode so i tried it and it solved the problem. Thanks you guys.

[PRossetti]

Hi! I'm having the same problem. I had this problem in some projects and after updating to Visual Studio Code 1.49.3 it's happening to me in all the projects so I cannot debug any of my applications. Please help! I don't know what else to try, I have already restarted the software several times, restarted the Mac and installing another versión of node with nvm but the problem keeps appearing.
Hope you can help me,
best regards!

[bpasero]

fyi @joaomoreno on my change. I really think this is not the right solution all in all because for a user you may be surprised that opening the first window always takes up to 10s (now 3s) without fully understanding what is going on in the background.

I think a setting for this could work, but is hard to discover too. Alternatively we could simply proceed with opening the workbench and let the process environment come in async with possibly an event to emit once that happens so that parties that need to update can subscribe to?

[joaomoreno]

But I really see no reason why resolving the shell environment would take any longer than <1s.

It happens a lot, and that's why it was set to 10.

Note that this blocks the window from opening, so it is really bad for performance

@jrieken made sure this doesn't block the window from opening, just the workbench from loading, back when he introduced lazyEnv. @bpasero, this is now known as whenEnvResolved, since your latest refactorings.

Overall, the user env is really only needed when further spawning more processes, so the real fix here is to just have an IExecutionService which should get the user env whenever spawning processes, instead of having that dependency in the renderer. This is a big refactoring which will likely break many things, but it's the right thing to do. I've created this item to follow up: #108804. Note that while the workbench will load more things, a lot of other things can't really work until the user env is loaded or timed out: terminals, tasks, extension host. Probably more, since we have configuration setting values which depend on environment values.... So that's fun.

Until then, I suggest to revert to the 10s timeout. Adding a setting for it is not good. Because every single user timing out will always file an issue before they even consider searching for a setting.

[bpasero]

@jrieken made sure this doesn't block the window from opening, just the workbench from loading, back when he introduced
lazyEnv. @bpasero, this is now known as whenEnvResolved, since your latest refactorings.

I really do not see how this good. The workbench not loading in 10s is equally bad as the window not loading in 10s. All that matters is the time to blinking cursor in the editor and that is what we measure in our perf runs.

#108804 sounds like a good idea and I think we should really tackle it soon not late.

Back to 3s vs 10s: what I don't like is this:

• even 10s might not be enough it is just a number you or Jo picked which may fail or may not fail
• if this happens (you wait 10s) there is no feedback as to why you waited for 10s
• users will never learn that they have to look into their shell config to figure out why VSCode is slow starting up

If we had a setting this would at least enable this flow:

• workbench starts slow
• we can show a notification offering to inform user why it was slow
• we can even notify that we could not resolve the shell environment in time
• we can guide users towards tweaking the setting to either reduce the time or increase it as needed

[alexrecuenco]

Sorry for interjecting,

I understand your concern @bpasero, but in my opinion ---from a user perspective--- it'd be better not to modify the current behavior. Thus avoiding a couple threads of confused people from undocumented behavior changed.

[milessa42]

I've had this same error happen recently as well, rendering VSCode useless for me until I figured out what was going on, and it took me a good bit of time to even figure out that this was the root cause, as I didn't get notified that the environment loading was timed out.

My eventual "resolution" was to disable extensions until my environment could be loaded in time. Given that I actually would like to use some of these extensions I disabled, I obviously can't consider this a real fix (this is something I will have to shelve VSCode for if it a must-have extension that is causing the problem, but I haven't gotten that far yet).

A setting to override the timeout would be great, I could change it and move on. The initial timeout is probably fine for a lot of people and the arguments for not having it set to 10s as a default are solid, but the lack of feedback about the environment not loading combined with the inability to override this behavior is a killer combination. I see that there is a feature request already put in to provide a real fix, but it would be amazing if, in the interim, we can get a setting + a prompt to update this setting if the environment load runs afoul of that timeout.

[sultanmyrza]

Developer: Reload Windows resolved my issue. Might not work for you just try. It worked for me.

[e-tip]

I have this issue too with 1.50. never had with 1.49 ( or at least it never happened ). Solved with Developer: Reload windows

[klemensz]

I've had the same problem with version 1.51.1 on macOS and solved (or worked around) it by re-starting VSCode.

[paullewisn]

Same problem Developer: Reload windows solved it

[bpasero]

Since I think the current solution is just wrong (blocking the startup to resolve shell environment waiting for N seconds), I will close this as duplicate of #108804 which is the correct solution: resolve the shell environment when it is needed. In that solution we will wait as long as it takes for the shell to spawn.

[matthew-dean]

In case anyone else comes across this, this problem started for me after installing the macOS Big Sur 11.1 update.

[vance]

I'm not on big sur, still get problems launching with debugger. restarting vs code fixes it.

Version: 1.52.1
Commit: ea3859d
Date: 2020-12-16T16:30:02.420Z (1 wk ago)
Electron: 9.3.5
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Darwin x64 19.6.0