Language server fails to start in macOS

[dlnash18]

Prerequisites

• I have written a descriptive issue title.
• I have searched all issues to ensure it has not already been reported.
• I have read the troubleshooting guide.
• I am sure this issue is with the extension itself and does not reproduce in a standalone PowerShell instance.
• I have verified that I am using the latest version of Visual Studio Code and the PowerShell extension.
• If this is a security issue, I have read the security issue reporting guidance.

Summary

When starting the extension, the language server does not start. VS Code gives up after four minutes and logs an error. This is the same symptom as described in #3782 and #3894, but I have an Intel Mac and I'm not using brew, starship, or fig as mentioned in those other two. I installed .NET via the macOS installer, and then installed PowerShell as a global tool. I am using macOS 12.3, which I know is untested as per PowerShell Support Lifecycle.

PowerShell Version

Name                           Value
----                           -----
PSVersion                      7.2.1
PSEdition                      Core
GitCommitId                    7.2.1
OS                             Darwin 21.4.0 Darwin Kernel Version 21.4.0: Mon Feb 21 20:34:37 PST…
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visual Studio Code Version

Version: 1.65.2
Commit: c722ca6c7eed3d7987c0d5c3df5c45f6b15e77d1
Date: 2022-03-10T14:33:49.188Z
Electron: 13.5.2
Chromium: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Darwin x64 21.4.0

Extension Version

ms-vscode.powershell-2021.12.0

Steps to Reproduce

1. Start with a fresh install of VS Code on macOS.
2. Install the PowerShell extension and no others.
3. Start the PowerShell extension.

Expected result

Extension and language server successfully start up.

Observed behavior

VS Code gives up and logs an error after four minutes waiting for the language server:

The language service could not be started:
Error: Timed out waiting for session file to appear.

Despite pwsh started appearing in the log, no pwsh process ever appears as observed by ps -ef | grep pwsh. However, one could have appeared and exited before I could see it.

If I dig the command line out of vscode-powershell.log and run it manually while VS Code is waiting for the language server, then VS Code successfully connects to it. However, I can't get to VS Code's built-in terminal to run the command, so I must do so in Terminal.app.

Visuals

No response

Logs

This is with diagnostic level logging turned on:

3/29/2022 6:54:02 PM [NORMAL] - Language server starting --
3/29/2022 6:54:02 PM [NORMAL] -     PowerShell Editor Services args: Import-Module '/Users/dlnash/.vscode/extensions/ms-vscode.powershell-2021.12.0/modules/PowerShellEditorServices/PowerShellEditorServices.psd1'; Start-EditorServices -HostName 'Visual Studio Code Host' -HostProfileId 'Microsoft.VSCode' -HostVersion '2021.12.0' -AdditionalModules @('PowerShellEditorServices.VSCode') -BundledModulesPath '/Users/dlnash/.vscode/extensions/ms-vscode.powershell-2021.12.0/modules' -EnableConsoleRepl -StartupBanner '=====> PowerShell Integrated Console v2021.12.0 <=====
' -LogLevel 'Diagnostic' -LogPath '/Users/dlnash/.vscode/extensions/ms-vscode.powershell-2021.12.0/logs/1648598042-915970d2-5399-44fa-9bc9-b9d90285a4351648597854493/EditorServices.log' -SessionDetailsPath '/Users/dlnash/.vscode/extensions/ms-vscode.powershell-2021.12.0/sessions/PSES-VSCode-37185-897582' -FeatureFlags @() 
3/29/2022 6:54:02 PM [NORMAL] - pwsh started.
3/29/2022 6:54:02 PM [NORMAL] - Waiting for session file
3/29/2022 6:54:02 PM [NORMAL] -     PowerShell executable: /Users/dlnash/.dotnet/tools/pwsh
3/29/2022 6:54:02 PM [NORMAL] -     PowerShell args: -NoProfile -NonInteractive -EncodedCommand SQBtAHAAbwByAHQALQBNAG8AZAB1AGwAZQAgACcALwBVAHMAZQByAHMALwBkAGwAbgBhAHMAaAAvAC4AdgBzAGMAbwBkAGUALwBlAHgAdABlAG4AcwBpAG8AbgBzAC8AbQBzAC0AdgBzAGMAbwBkAGUALgBwAG8AdwBlAHIAcwBoAGUAbABsAC0AMgAwADIAMQAuADEAMgAuADAALwBtAG8AZAB1AGwAZQBzAC8AUABvAHcAZQByAFMAaABlAGwAbABFAGQAaQB0AG8AcgBTAGUAcgB2AGkAYwBlAHMALwBQAG8AdwBlAHIAUwBoAGUAbABsAEUAZABpAHQAbwByAFMAZQByAHYAaQBjAGUAcwAuAHAAcwBkADEAJwA7ACAAUwB0AGEAcgB0AC0ARQBkAGkAdABvAHIAUwBlAHIAdgBpAGMAZQBzACAALQBIAG8AcwB0AE4AYQBtAGUAIAAnAFYAaQBzAHUAYQBsACAAUwB0AHUAZABpAG8AIABDAG8AZABlACAASABvAHMAdAAnACAALQBIAG8AcwB0AFAAcgBvAGYAaQBsAGUASQBkACAAJwBNAGkAYwByAG8AcwBvAGYAdAAuAFYAUwBDAG8AZABlACcAIAAtAEgAbwBzAHQAVgBlAHIAcwBpAG8AbgAgACcAMgAwADIAMQAuADEAMgAuADAAJwAgAC0AQQBkAGQAaQB0AGkAbwBuAGEAbABNAG8AZAB1AGwAZQBzACAAQAAoACcAUABvAHcAZQByAFMAaABlAGwAbABFAGQAaQB0AG8AcgBTAGUAcgB2AGkAYwBlAHMALgBWAFMAQwBvAGQAZQAnACkAIAAtAEIAdQBuAGQAbABlAGQATQBvAGQAdQBsAGUAcwBQAGEAdABoACAAJwAvAFUAcwBlAHIAcwAvAGQAbABuAGEAcwBoAC8ALgB2AHMAYwBvAGQAZQAvAGUAeAB0AGUAbgBzAGkAbwBuAHMALwBtAHMALQB2AHMAYwBvAGQAZQAuAHAAbwB3AGUAcgBzAGgAZQBsAGwALQAyADAAMgAxAC4AMQAyAC4AMAAvAG0AbwBkAHUAbABlAHMAJwAgAC0ARQBuAGEAYgBsAGUAQwBvAG4AcwBvAGwAZQBSAGUAcABsACAALQBTAHQAYQByAHQAdQBwAEIAYQBuAG4AZQByACAAJwA9AD0APQA9AD0APgAgAFAAbwB3AGUAcgBTAGgAZQBsAGwAIABJAG4AdABlAGcAcgBhAHQAZQBkACAAQwBvAG4AcwBvAGwAZQAgAHYAMgAwADIAMQAuADEAMgAuADAAIAA8AD0APQA9AD0APQAKACcAIAAtAEwAbwBnAEwAZQB2AGUAbAAgACcARABpAGEAZwBuAG8AcwB0AGkAYwAnACAALQBMAG8AZwBQAGEAdABoACAAJwAvAFUAcwBlAHIAcwAvAGQAbABuAGEAcwBoAC8ALgB2AHMAYwBvAGQAZQAvAGUAeAB0AGUAbgBzAGkAbwBuAHMALwBtAHMALQB2AHMAYwBvAGQAZQAuAHAAbwB3AGUAcgBzAGgAZQBsAGwALQAyADAAMgAxAC4AMQAyAC4AMAAvAGwAbwBnAHMALwAxADYANAA4ADUAOQA4ADAANAAyAC0AOQAxADUAOQA3ADAAZAAyAC0ANQAzADkAOQAtADQANABmAGEALQA5AGIAYwA5AC0AYgA5AGQAOQAwADIAOAA1AGEANAAzADUAMQA2ADQAOAA1ADkANwA4ADUANAA0ADkAMwAvAEUAZABpAHQAbwByAFMAZQByAHYAaQBjAGUAcwAuAGwAbwBnACcAIAAtAFMAZQBzAHMAaQBvAG4ARABlAHQAYQBpAGwAcwBQAGEAdABoACAAJwAvAFUAcwBlAHIAcwAvAGQAbABuAGEAcwBoAC8ALgB2AHMAYwBvAGQAZQAvAGUAeAB0AGUAbgBzAGkAbwBuAHMALwBtAHMALQB2AHMAYwBvAGQAZQAuAHAAbwB3AGUAcgBzAGgAZQBsAGwALQAyADAAMgAxAC4AMQAyAC4AMAAvAHMAZQBzAHMAaQBvAG4AcwAvAFAAUwBFAFMALQBWAFMAQwBvAGQAZQAtADMANwAxADgANQAtADgAOQA3ADUAOAAyACcAIAAtAEYAZQBhAHQAdQByAGUARgBsAGEAZwBzACAAQAAoACkAIAA=
3/29/2022 6:54:02 PM [VERBOSE] - <qo>: Unable to send getCommand request
3/29/2022 6:58:02 PM [NORMAL] - Timed out waiting for session file to appear.
3/29/2022 6:58:02 PM [NORMAL] - Language server startup failed.
3/29/2022 6:58:02 PM [ERROR] - The language service could not be started: 
3/29/2022 6:58:02 PM [ERROR] - Error: Timed out waiting for session file to appear.

[andyleejordan]

Hello! The latest code is available in the PowerShell Preview for VS Code, and includes a myriad of fixes. Could you verify if this issue still reproduces using the preview extension? Please note that this preview is likely to include other bugs, and you should feel free to file new issues for those so we can work through them. Thanks again!

[dlnash18]

I should have said so already, but I tried the Preview before opening this issue. No change.

[andyleejordan]

/Users/dlnash/.dotnet/tools/pwsh

This is an interesting location for PowerShell.

I installed .NET via the macOS installer, and then installed PowerShell as a global tool.

I've never heard of this approach for installing pwsh (just dotnet tools like dotnet-format), and I don't see a NuGet package for pwsh. Can you expand on this?

[dlnash18]

Yep, I thought it was an odd location as well. Instructions for this method of installation are here. It boils down to one command: dotnet tool install --global PowerShell. I figured "global" meant it would put it in some suitably global location, but apparently not. I did it this way because I wanted to install .NET separately so I'd get the full SDK. The documentation for installing PowerShell isn't clear on whether I'd get that using any of the other installation methods.

With pwsh installed in such an odd location, it made me wonder if VS Code was failing to exec() it properly. So I put a symlink from /usr/local/bin/pwsh to the real location. It didn't help, which then made me wonder if launchd's default PATH of /usr/bin:/bin:/usr/sbin:/sbin is somehow playing into this. But clearly something is finding it, since it's showing up in the log.

[andyleejordan]

What do you see in the session menu? ("Show Session Menu" command in the palette.) I just followed those instructions and the extension auto-found it that location, and successfully launched. I also tried this setting:

    "powershell.powerShellAdditionalExePaths": [
        {
            "versionName": "My .NET PowerShell",
            "exePath": "/Users/andschwa/.dotnet/tools/pwsh"
        }
    ],

and it worked as well.

[andyleejordan]

Can you launch PowerShell from that binary in a terminal?

[dlnash18]

[dlnash18]

That path is how I always start pwsh in a terminal. My PATH variable includes ~/.dotnet/tools. Adding powershell.powerShellAdditionalExePaths to my settings (and s/andschwa/dlnash/ of course) didn't help.

[dlnash18]

I just upgraded to VS Code 1.66.0, and that didn't change anything.

[andyleejordan]

Hm, in a regular VS Code terminal, can you launch pwsh at that path and run it? macOS has a lot of permissions around first-launch of binaries.

[dlnash18]

Well there's your problem:

I don't know where those /opt paths are coming from. launchctl says that the default path supplied by launchd is /usr/bin:/bin:/usr/sbin:/sbin. But yeah, definitely no ~/.dotnet/tools, and no /usr/local either, which explains why my symlink trick didn't work.

[dlnash18]

But wait, it gets better! Trying to run pwsh directly results in a great stack dump:

[eis1-a33069:~] dlnash% .dotnet/tools/pwsh 
Unhandled exception. System.ComponentModel.Win32Exception (2): An error occurred trying to start process 'dotnet' with working directory '/Users/dlnash'. No such file or directory
   at System.Diagnostics.Process.ForkAndExecProcess(ProcessStartInfo startInfo, String resolvedFilename, String[] argv, String[] envp, String cwd, Boolean setCredentials, UInt32 userId, UInt32 groupId, UInt32[] groups, Int32& stdinFd, Int32& stdoutFd, Int32& stderrFd, Boolean usesTerminal, Boolean throwOnNoExec)
   at System.Diagnostics.Process.StartCore(ProcessStartInfo startInfo)
   at System.Diagnostics.Process.Start()
   at System.Diagnostics.Process.Start(ProcessStartInfo startInfo)
   at System.Diagnostics.Process.Start(String fileName, String arguments)
   at Microsoft.PowerShell.GlobalTool.Shim.EntryPoint.Main(String[] args)
Abort
[eis1-a33069:~] dlnash% 

"No such file or directory"? Huh? It only does that inside VS Code's terminal. If I use Terminal.app, it's fine.

[andyleejordan]

Hm...check the security settings in macOS for the Code app. The OS sandboxes access to folders nowadays, perhaps Code was denied filesystem access to ~/.dotnet.