Connection to terminal's pty host process is becoming unresponsive

[triforcely]

Issue Type: Bug

After updating to latest VSCode stable (1.59) I started encountering an error when running tasks (The connection to the terminal's pty host process is unresponsive, the terminals may stop working.). This used to work fine on 1.58.2 and I confirmed that it is broken on latest insider build too (1.60.0)

I have a bunch of VSCode tasks for 'orchestrating' local docker setup, so I can run some commands to run builds and generate TypeScript clients directly from the UI. When I run tasks without any "dependsOn" tasks they run fine. If one task depends on single other task, it also runs fine. I have problems when single task have multiple entries in "dependsOn" section - it usually works fine for the first time after I open VSCode but then the issue happens and I have to fully restart VSCode to make it work again.

VS Code version: Code - Insiders 1.60.0-insider (49af1cb, 2021-08-06T06:41:50.275Z)
OS version: Windows_NT x64 10.0.19042
Restricted Mode: No

System Info

Item	Value
CPUs	AMD Ryzen 9 3900X 12-Core Processor (24 x 3800)
GPU Status	2d_canvas: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on rasterization: enabled skia_renderer: enabled_on video_decode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled
Load (avg)	undefined
Memory (System)	31.93GB (18.13GB free)
Process Argv	--crash-reporter-id 99c6e3ee-c17a-4f3a-a118-c9cbac23e0db
Screen Reader	no
VM	0%

Extensions (1)

Extension	Author (truncated)	Version
csharp	ms-	1.23.14

A/B Experiments

vsliv695:30137379
vsins829:30139715
vsliv368:30146709
vsreu685:30147344
python383cf:30185419
pythonvspyt602:30291494
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyt639:30291487
pythontb:30258533
pythonvspyt551:30291412
pythonptprofiler:30281269
vshan820:30294714
pythondataviewer:30285072
pythonvsuse255:30319630
vscod805:30301674
pythonvspyt200:30323110
vsccppwt:30312692
pythonvssor306:30340298
bridge0708:30335490
pygetstartedt2:30348854
dockerwalkthru:30348713

Tasks hierarchy

{
      "label": "[Debug] Create base image for Api container",
      "command": "powershell",
      "args": [
        "docker",
        "build",
        "--rm",
        "-f",
        "${workspaceFolder}/BaseImage.Debug.Dockerfile",
        "-t",
        "baseimage-api-debug:latest",
        "."
      ]
    },
    {
      "label": "[Debug] Create image for Api.Dockerfile",
      "command": "powershell",
      "args": [
        "docker",
        "build",
        "--rm",
        "-f",
        "${workspaceFolder}/Api.Dockerfile",
        "-t",
        "backend-core-debug:latest",
        "."
      ],
      "problemMatcher": {
        "base": "$msCompile",
        "fileLocation": [
          "relative",
          "${workspaceRoot}"
        ]
      },
      "dependsOn": [
        "[Debug] Create base image for Api container"
      ]
    },
    {
      "label": "[Debug] Create image for Hangfire.Server.Dockerfile",
      "command": "powershell",
      "args": [
        "docker",
        "build",
        "--rm",
        "-f",
        "${workspaceFolder}/Hangfire.Server.Dockerfile",
        "-t",
        "hangfire-server-debug:latest",
        "."
      ],
      "problemMatcher": {
        "base": "$msCompile",
        "fileLocation": [
          "relative",
          "${workspaceRoot}"
        ]
      },
      "dependsOn": [
        "[Debug] Create base image for Api container"
      ]
    },
    {
      "label": "[Debug] Create service for docker-compose.dev.yml",
      "command": "powershell",
      "args": [
        "docker-compose",
        "-f",
        "${workspaceFolder}/docker-compose.dev.yml",
        "up",
        "-d",
        "--build",
        "--force-recreate",
        "--renew-anon-volumes"
      ],
      "problemMatcher": "$msCompile",
      "dependsOn": [
        "[Debug] Create image for Api.Dockerfile", 
        "[Debug] Create image for Hangfire.Server.Dockerfile"
      ]
    },
    {
      "label": "[TS] generate libraries",
      "type": "shell",
      "command": "\"${workspaceRoot}/../_scripts/wait-for-it-http.ps1\" && nswag.cmd run || docker logs backend-core_api_1",
      "problemMatcher": "$msCompile",
      "options": {
        "cwd": "${workspaceRoot}/../tt-ts-core"
      },
      "dependsOn": [
        "[Debug] Create service for docker-compose.dev.yml"
      ]
    }

[JBaczuk]

Every time I wake my mac up from sleep (since the latest update to 1.59.1) I get this too:

A lot of times all the terminal processes are still running too, so I have to open Activity Monitor to force close them.

[xianghongai]

"terminal.integrated.windowsEnableConpty": false

restart vs code ...

[xianghongai]

Duplicate of #117956, #118606

[Tyriar]

@xianghongai that issue should be fixed already.

[Airmail50]

I got this earlier all the time and then I deleted everything and now I get it when I try to download python extension back. Tried older versions of both python and vscode and vscode insiders but cant find a fix.

[lorand-horvath]

I confirm this error "The connection to the terminal's pty host process is unresponsive, the terminals may stop working." since I've updated my Windows 7 installation to latest version.

I used to have a very old Windows 7 x64 from 2014 without any updates installed - all versions of VSCode up to 1.67 were running with absolutely no problems related to the terminal. Then, after I updated Windows 7 to latest available as of June 2022, the same VSCode I had installed started to throw this error, with the terminal (Command Prompt / CMD) disconnecting frequently (perhaps every 10-20 minutes or so).

I've even disabled the ConPTY to fall back to Winpty, but the exact same issue occurs, it doesn't help at all.

I hope this report helps the devs in finding out the underlying cause of the error and perhaps a fix....

[lorand-horvath]

@meganrogge I'm trying to find a solution to this annoying issue. Can you point me in the right direction, please?

[lorand-horvath]

@meganrogge I have the exact same issue with the latest VSCode 1.68. Is there something I can tryor do? Could you point me in the right direction so we can solve this?

[Tyriar]

@lorand-horvath you should update windows, Windows 7 was EOL in 2020 https://www.microsoft.com/en-us/windows/windows-7-end-of-life-support-information#:~:text=After%2010%20years%2C%20support%20for,ended%20on%20January%2014%2C%202020. Also you never got to use conpty as it's only in the later versions of Windows 10.

[lorand-horvath]

@meganrogge @Tyriar I'm still getting this error, but since last Friday June 24th (I'm using Insiders) the terminal recovers after about 1-2 minutes, which is very interesting. I'm not sure what has changed (for the better!), but after about a minute the connection to the terminal is restored automatically and I can continue working in it, without losing any previous information. Before June 24 the terminal never recovered or restored connection and I had to kill it and open another instance and start all over again.

The restored connection notification is being logged to the devtools console as The pty host became responsive again so I get a series of the following connection lost/restored cycles:

The connection to the terminal's pty host process is unresponsive, the terminals may stop working.
INFO The pty host became responsive again

Is there some kind of timeout involved here? I've read about a 10 second timeout, but I'm not sure where I can access and hopefully increase the value of? I've noticed this error occurs mostly if the terminal and/or VSCode itself is not being focused on for several minutes and I think it may be related to the occlusion tracker kicking in (just a thought).
I would very much appreciate if you could provide any insight into increasing the timeout (if there's any possibility for that, of course). I'm willing to experiment, that's not an issue. Thanks a lot for your work!

[Tyriar]

Here are the timeouts related to the pty host heartbeat/responsiveness:

vscode/src/vs/platform/terminal/common/terminal.ts

Lines 368 to 390 in f6786c8

	export enum HeartbeatConstants {
	/**
	* The duration between heartbeats
	*/
	BeatInterval = 5000,
	/**
	* Defines a multiplier for BeatInterval for how long to wait before starting the second wait
	* timer.
	*/
	FirstWaitMultiplier = 1.2,
	/**
	* Defines a multiplier for BeatInterval for how long to wait before telling the user about
	* non-responsiveness. The second timer is to avoid informing the user incorrectly when waking
	* the computer up from sleep
	*/
	SecondWaitMultiplier = 1,
	/**
	* How long to wait before telling the user about non-responsiveness when they try to create a
	* process. This short circuits the standard wait timeouts to tell the user sooner and only
	* create process is handled to avoid additional perf overhead.
	*/
	CreateProcessTimeout = 5000
	}

You cannot customize them currently, if there's no communication between the 2 processes in 10+ seconds then there is something very wrong, allowing configuration here wouldn't be a great workaround.

[lorand-horvath]

@Tyriar That's interesting! Any reason why there's no communication between the app and the terminal processes for more than 10 seconds when VSCode is not focused on? In the latest Insiders from today I've noticed that the connection loss ONLY occurs if I'm not focused on/working in VSCode. So if I work in another program (let's say Postman or a browser) and have VSCode open on my other screen with its terminal open with a Node.js app running in it, it will lose connection after a while (it takes quite a while, maybe 10-20 minutes).

Is there any chance to debug/fix this? The possibility of customizing the pty host heartbeat parameters (even if hidden, for dev purposes only) would certainly help! I have a feeling that waiting just a bit more (i.e. 12-15 instead of 10 seconds) before notifying would maintain the connection without issues for long periods of time, even if VSCode is not actively being focused on.

Alternatively, do you know of any other, more general setting in VSCode (perhaps Electron-related) that would turn off the delay in inter-process communication? I recon there must be some kind of delay or slumber mode kicking in when the window gets un-focused. I'm thinking of something like starting VSCode with the native occlusion flag disabled, i.e. --disable-features=CalculateNativeWinOcclusion. Is there anything similar that we can use in this case for debugging? Even a temporary access to the BeatInterval value you mentioned, in the next Insiders release, would be valuable. Thanks again!

Edit: I see there's another parameter GraceTime = 60000 described as If there is no reconnection within this time-frame, consider the connection permanently closed..
It looks like the reconnect is always happening within this GraceTime period of 60 seconds, so I never lose access to the terminal completely. It means the 10 second timeout is a bit low, at least in my case. Problem is, it can get quite difficult to work while this error/disconnect pops up every 10-20 minutes.

[lorand-horvath]

@Tyriar I've been investigating by increasing the BeatInterval value above 5000 in C:\Program Files\Microsoft VS Code Insiders\resources\app\out\vs\platform\terminal\node\ptyHostMain.js. So instead of 5s I've tried 10s, 15s with various improvements in the frequency of terminal disconnections.

Do you think this is a proper way of testing? I'm not sure how to go about otherwise...

[lorand-horvath]

This is unbelievably frustrating... After a clean install of latest Insiders the warning pops up without even starting the terminal in the first place! I have no extensions installed, nothing. It's clean as possible. What is going on? Anyone else struggling with this?

[renzedj]

Having this same issue in macOS as of today. Per @meganrogge recommendation on #156668, I set terminal.integrated.enablePersistentSessions: false, but am still having this issue. It's persisted through a complete wipe of settings and a fresh install.

[meganrogge]

Thanks for your patience @drenze-athene it's hard for us to investigate this kind of issue when we cannot reproduce it. Did you start seeing it after a specific version of VS Code? You could try reverting to an older one

[renzedj]

Thanks for your patience @drenze-athene it's hard for us to investigate this kind of issue when we cannot reproduce it. Did you start seeing it after a specific version of VS Code? You could try reverting to an older one

I understand, not a problem. Right now I'm on 1.69.2, just upgraded from a 1.5x.x release a few days ago (1.57.x, I think). I was experiencing it then, which is why I upgraded. My issue with knowing what version I'm using is that I'm in an Enterprise environment and upgrades are centrally managed, so I don't usually upgrade myself unless I'm experiencing a specific issue, such as this. AFAIK I'm the only one in our environment who is experiencing this issue right now, so I'm checking to see what version others are using and may downgrade, if appropriate.

[renzedj]

@meganrogge -

Thanks for your patience @drenze-athene it's hard for us to investigate this kind of issue when we cannot reproduce it. Did you start seeing it after a specific version of VS Code? You could try reverting to an older one

In my case, this appears to be an unrelated issue, which causes the same symptoms in VSCode. Our Service Desk fixed another issue for me this morning, which caused general slowness, and this issue appears to be resolved as well.

[lorand-horvath]

[AnrDaemon]

Thanks, Megan. I'm travelling and don't have time for playing with Insiders ATM. Will wait for next release and use separate tunnel for the time being.

[Nevrai]

I've closed this out with the following changes:

• We now wait 20 seconds before the first heartbeat (26 seconds before notification) Wait 20 seconds for first pty host heartbeat #185258
• The pty host responsiveness alert is moving to the status bar to be less intrusive Change the pty host responsiveness notification to a status bar item #185255
• Better logs and debug settings to help spot and diagnose these sorts of issues Improve pty host diagnostics and introduce hidden simulated latency settings #185243

I also spotted a few other issues with slow pty hosts which I'll look into if time allows this release: #185254, #185256, #185257

Note that this is actioning the most recent issue, not longer standing problems. This issue has been a bit of a dumping ground for all the problems so it's probably best to hit the reset button and create a new issue if there are remaining issues after all the changes that have gone in recently.

Thank you. Will the fixes be implemented in the near future?

[gjsjohnmurray]

@DeleteMetaInf please see above at #130320 (comment)

[astroganga]

Same issue here. On three different Windows 10 systems I get the error message on 1.79.1 whenever I start the editor.
Downgrading to version 1.78.2 solves the problem.

I solved it with your downgrade method, thank you!

I am on Red Hat Linux Enterprise. Same issue on 1.79.2. I solved with downgrade method (1.78.2)

[yanabcd]

I also have this problem,it 's so hard for me.I'dont kown why.extensive or use python programm?

[aiday-mar]

Hey! Sorry I unpinned the issue by accident

[laccd-minassn]

Would like to add that I was having this problem with v 1.79.2 on Fedora Linux with Gnome desktop. I installed the insiders edition v1.80.0 and I no longer have this issue for what it's worth.

I would get "The connection to the terminal's pty host process is unresponsive" and after about 2 minutes, the terminal would finally show up. Comes up instantly in 1.80.0

[AnrDaemon]

"The connection to the terminal's pty host process is unresponsive"

This message comes up on 1.79.2 startup but disappears after a short while.

[exosomal]

Why is this closed, the problem still exists.

[laccd-minassn]

It's fixed in 1.80+ so I guess there's no reason to keep it open.

[Tyriar]

Sorry about the hassle all, this is fixed in v1.80.0 which we're targeting to release Thursday the 6th ~11am PST