Powershell integrated terminal in VSCode doesn't start up.

[Diederikjh]

System Details

• Operating system name and version: Ubuntu 16.04
• VS Code version: 1.25.0
• PowerShell extension version: 1.8.0
• Output from $PSVersionTable: (see below)

Copy / paste the following commands into the PowerShell Integrated Console, and paste the output here:  

As I can't start the integrated terminal, I ran these commands in normal powershell, ran via bash.

code -v
1.25.0
0f080e5267e829de46638128001aeb7ca2d6d50e
x64
$pseditor.EditorServicesVersion
<no output>
code --list-extensions --show-versions
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
$PSVersionTable
Name                           Value
----                           -----
PSVersion                      6.1.0-preview.2
PSEdition                      Core
GitCommitId                    v6.1.0-preview.2
OS                             Linux 4.4.0-130-generic #156-Ubuntu SMP Thu Jun 14 08:53:28 UTC 2018
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Issue Description

I had a working Powershell integrated terminal and debugger just yesterday, using the old version of the Powershell extension.

VS code had a non clean exit (As my system locked up).

This morning I started Visual Studio Code and the integrated terminal doesn't work. Neither does the debugger. The Powershell extension also updated today.

After the terminal tries to launch it shows:

PowerShell Integrated Console Permissions to the pipe file were not set properly. Expected: 600 Actual: srw------- for file: /tmp/CoreFxPipe_PSES_5b0a428f-e0b7-4e90-b8c8-d0a44966a752

And after a while the terminal closes. Logs below:

the pwsh app seems to work fine in normal bash.

I tried to delete all the pipe like files with the following command:
rm /tmp/CoreFxPip* in the hope that it would re-create them correctly, but that didn't make a difference.

I tried to set the permissions correctly on the file it was complaining about (by running chmod 600 on the file it was complaining about) but that doesn't seem to work: it seems to re-create the files with incorrect permissions.

Running VSCode as root doesn't seem to help either (glad it is very loud about warning the user not to do this).

I did find this old issue but this seems to be more windows specific.

Attached Logs

2018-7-11 08:39:32 [NORMAL] - Syntax Folding Provider registered
2018-7-11 08:39:32 [NORMAL] - powershell.exe started, pid: 8751
2018-7-11 08:39:38 [NORMAL] - powershell.exe terminated or terminal UI was closed
2018-7-11 08:40:32 [NORMAL] - Language server startup failed.
2018-7-11 08:40:32 [ERROR] - The language service could not be started: 
2018-7-11 08:40:32 [ERROR] - Timed out waiting for session file to appear.

Verbose logs attached.
logs.zip

[fcharlie]

see #1421

./modules/PowerShellEditorServices/Start-EditorServices.ps1:227

replace

        $mode = stat -c "%A" $PipeFile

to

        $mode = stat -c "%a" $PipeFile

[Diederikjh]

Awesome, thanks. Seems to have fixed it. I also replaced the other occurrence of %A with %a 2 lines down.

[fcharlie]

@Diederikjh Maybe only linux need fix.

[Diederikjh]

Your probably right.

The debugger sometimes seems to crash on me. Not sure if it is related to the above changes.

Attached logs of crash (folder in zip file with name 1531297271-01474be5-727d-4a9f-99e3-32a83afee6f41531297269484 probably good place to start looking)

logs.zip

[rjmholt]

@Diederikjh, @fcharlie Can you please update your extension to 1.8.1 (just released then) and see if this issue is fixed?

[Diederikjh]

Looks good for now. Terminal starts up, and debugging looks more stable.
Thanks

[Diederikjh]

I think this has regressed.

I'm getting
Permissions to the pipe file were not set properly. Expected: 600 Actual: for file: /tmp/CoreFxPipe_PSES_358c3f85-31c0-44b0-894c-802a7400bf55

When starting a PowerShell debugger.

Powershell Extension version is 1.8.4.

VS Code version is 1.27.2

[rjmholt]

@Diederikjh The last change was this one to use the full path of the stat binary (since this didn't work for users with custom stat installs).

Can you try changing the file back to just stat and reporting back?

[Diederikjh]

Just tried that:

if ($IsLinux) {
    $mode = stat -c "%a" $PipeFile
}
elseif ($IsMacOS) {
    $mode = /usr/bin/stat -f "%A" $PipeFile
}

Same behavior unfortunately.

[rjmholt]

Hmmm, as far as I know that behaviour hasn’t been changed otherwise.

Have you upgraded PowerShell version?

[TylerLeonhardt]

There hasn't been any other changes to that area. Did you update your Mac recently?

If you do /usr/bin/stat -f "%A" somefile.txt

Do you get the expected value? Should be a 3 digit number.

[Diederikjh]

I'm running on Ubuntu.
Yes I think a system update did do a Powershell update.
Running
/usr/bin/stat -c "%a" ./somefile.pdf
Returns
644

[TylerLeonhardt]

And what about just:

stat -c "%a" ./somefile.pdf

Since that's the actual code path you're going through. I expect it to be the same

[Diederikjh]

Yep, the same.

Ive tried reproducing this issue in another system, and can't. Only difference I can see is the VSCode version where it does work is a bit older: 1.27.1

Both systems Ubuntu

[TylerLeonhardt]

Hmmm... Do you happen to remember how you opened vscode? With the code CLI or something else?

[Diederikjh]

GUI on both systems.

<Win> -> code -> down arrow -> enter

[TylerLeonhardt]

I wonder if there's a bug in vscode where we don't have access to the path anymore...

If you open in via a terminal, does that change anything?

[Diederikjh]

Starting from console (on both systems) has same behavior.

[rjmholt]

Can you paste the contents of ~/.vscode/extensions/ms-vscode.powershell-1.8.4/modules/PowerShellEditorServices/Start-EditorServices.ps1?

[Diederikjh]

From system where it doesn't work:
https://gist.github.com/Diederikjh/359977fdebd2b35d7a728978cfc97403
Modified as suggested above.

(On system where it does work:
https://gist.github.com/Diederikjh/2ca3c158d679481c338581c59d125e77 should be unmodified.)

[rjmholt]

I just did a diff of the two:

> diff ./f1.ps1 ./f2.ps1
235c235
<         $mode = stat -c "%a" $PipeFile
---
>         $mode = /usr/bin/stat -c "%a" $PipeFile

So it's not a change in Start-EditorServices.ps1 that's caused it I don't think.

Might be worth putting a Write-Host in your newer version of the file to check that $mode is what we think it is there.

Can you post the result of the following commands:

• cat /etc/lsb_release
• uname -a
• stat --version

I've been developing PSES chiefly from an Ubuntu 18.04 LTS machine recently and really not sure what would be causing this to occur in your environment.

[Diederikjh]

$ lsb_release  -a
LSB Version:	core-9.20160110ubuntu0.2-amd64:core-9.20160110ubuntu0.2-noarch:security-9.20160110ubuntu0.2-amd64:security-9.20160110ubuntu0.2-noarch
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.5 LTS
Release:	16.04
Codename:	xenial

$ uname -a
Linux djh-xyz-wks 4.4.0-135-generic #161-Ubuntu SMP Mon Aug 27 10:45:01 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

$ stat --version
stat (GNU coreutils) 8.25
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Michael Meskes.

All of above same as system where it works

[Diederikjh]

I didn't notice this before, but when starting up the PowerShell terminal it complains:

/bin/chmod: cannot access '/tmp/CoreFxPipe_PSES_6e5abefe-aa32-4947-aa39-d4367df2d443': No such file or directory
/usr/bin/stat: cannot stat '/tmp/CoreFxPipe_PSES_6e5abefe-aa32-4947-aa39-d4367df2d443': No such file or directory

Obviously those files doesn't exist.

[rkeithhill]

Is there something unusual about the /tmp dir or the perms on the /tmp dir?

[Diederikjh]

Doesn't look like it. ls -l / gives

drwxrwxrwt 25 root root 36864 Sep 21 06:48 tmp

[Diederikjh]

So I have no idea what changed, but had to do some pwsh development today, and everything seem to work as expected. A VSCode or plugin (or system?) upgrade must have fixed it along the line.

[rjmholt]

I'm still mystified by this -- we tried reproducing it several times on different Linux platforms but couldn't. Good to know it's working @Diederikjh -- let us know if it stops again.

[qwertoyo]

Hi! I'm in the future but I had this issue while attaching vscode with the powershell extension to an Alpine-based container (we needed to debug some pwsh there) and I "fixed" it just copying stat bin where the extension was expecting it.

Error:

An error occurred while starting PowerShell Editor Services:
The term '/usr/bin/stat' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
at System.Management.Automation.ExceptionHandlingOps.CheckActionPreference(FunctionContext funcContext, Exception exception)
at System.Management.Automation.Interpreter.ActionCallInstruction2.Run(InterpretedFrame frame) at >System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame) at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame) at System.Management.Automation.Interpreter.Interpreter.Run(InterpretedFrame frame) at System.Management.Automation.Interpreter.LightLambda.RunVoid1[T0](T0 arg0) at System.Management.Automation.PSScriptCmdlet.RunClause(Action1 clause, Object dollarUnderbar, Object inputToProcess)
at System.Management.Automation.PSScriptCmdlet.DoEndProcessing()
at System.Management.Automation.CommandProcessorBase.Complete()

"fix" (in my dockerfile):

RUN cp /bin/stat /usr/bin/stat

[TylerLeonhardt]

We no longer rely on stat in the PowerShell Preview (coming to Stable next month)

So you shouldn't have to do this if you use that. 😊

[solomonsunder]

I have this issue on the Temporary Powershell Integrated Console when I click Debug.

PowerShell Integrated Console

/bin/chmod: cannot access '/tmp/CoreFxPipe_PSES_zhv4igvh.xwb': No such file or directory

/usr/bin/stat: cannot stat '/tmp/CoreFxPipe_PSES_zhv4igvh.xwb': No such file or directory

Permissions to the pipe file were not set properly. Expected: 600 Actual: for file:

/tmp/CoreFxPipe_PSES_zhv4igvh.xwb

After a while I get a timeout waiting for the powershell extension to start pop up.

I am on Ubuntu 18.04.4 LTS

[TylerLeonhardt]

@solomonsunder please read this comment above yours:
#1422 (comment)

[solomonsunder]

@TylerLeonhardt @rjmholt Thanks. It works with Powershell Preview, though it does give some error while firing up.

Unable to find type [Microsoft.PowerShell.PSConsoleReadLine].
At line:1 char:71

• ... :RunClassConstructor([Microsoft.PowerShell.PSConsoleReadLine].TypeHan ...

•                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  

• CategoryInfo : InvalidOperation: (Microsoft.PowerShell.PSConsoleReadLine:TypeName) [], RuntimeException
• FullyQualifiedErrorId : TypeNotFound

By the way, is it expected behavior for the TEMP Powershell Integrated Console to not have the modules that was imported into the original console? For eg I had to put Import-Module AWSPowerShell.NetCore in the script.

[rjmholt]

is it expected behavior for the TEMP Powershell Integrated Console to not have the modules that was imported into the original console?

Absolutely; the TEMP console is supposed to be a clean session.

Unable to find type [Microsoft.PowerShell.PSConsoleReadLine].

That's a worry. Can you open a new issue for that with the full error message and the output of gmo -list PSReadLine?

[TylerLeonhardt]

Unable to find type [Microsoft.PowerShell.PSConsoleReadLine].

If you use PowerShell 7, this will go away... but I also have PR out to fix this:
PowerShell/PowerShellEditorServices#1200