vscode-remote-release
vscode-remote-release copied to clipboard
Remote WSL Disconnects eventually
Issue Type: Bug
Sometimes It disconnects. I need to shutdown the distro and start it up again to get to connect to remote WSL on vs again
Extension version: 0.54.6 VS Code version: Code 1.54.3 (2b9aebd5354a3629c3aba0a5f5df49f43d6689f8, 2021-03-15T10:55:45.459Z) OS version: Windows_NT x64 10.0.19042 Remote OS version: Linux x64 4.19.104-microsoft-standard
System Info
| Item | Value |
|---|---|
| CPUs | AMD Ryzen 5 2600 Six-Core Processor (12 x 3394) |
| GPU Status | 2d_canvas: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on protected_video_decode: unavailable_off rasterization: enabled skia_renderer: enabled_on video_decode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled |
| Load (avg) | undefined |
| Memory (System) | 15.95GB (4.56GB free) |
| Process Argv | --crash-reporter-id ac9558df-afaf-470a-abff-4d7498782e3a |
| Screen Reader | no |
| VM | 0% |
| Item | Value |
|---|---|
| Remote | WSL: Ubuntu-20.04 |
| OS | Linux x64 4.19.104-microsoft-standard |
| CPUs | AMD Ryzen 5 2600 Six-Core Processor (2 x 3393) |
| Memory (System) | 3.84GB (0.22GB free) |
| VM | 0% |
A/B Experiments
vsliv368cf:30146710
vsreu685:30147344
python383:30185418
pythonvspyt700cf:30270857
vspor879:30202332
vspor708:30202333
vspor363:30204092
vswsl492:30256859
vstry914:30276682
pythonvsdeb440:30248342
pythonvsded773:30248341
pythonvspyt875:30259475
pythonvsnew554:30281908
pythontb:30265425
wslfolderdoccf:30282075
vspre833cf:30267465
pythonptprofiler:30281270
vshan820cf:30276953
Same issue +1
Same issue + 1 2 days ago I have updated it from wsl1 to ws2 and it disconnects almost every 35minutes. Event with VSCode Insiders
I was reading https://github.com/microsoft/vscode-remote-release/issues/4536, it looks the same problem. The solution there was raise the memory limit.
I'm currently using 4gb limit, I'll test it with 5gb. I'll share with you later my tests.
Guys I'm running with 5GB memory limit for ~4h straight and it seems to be working fine
I'll keep testing, anything out of expected I'll post it here. but it's all right so far.
Guys I'm running with 5GB memory limit for ~4h straight and it seems to be working fine
I'll keep testing, anything out of expected I'll post it here. but it's all right so far.
I set the limit as follow, i'll see if with this option will work...
[wsl2]
memory=5GB
processors=2
Just as another reminder here is the step to change the settings:
- Open PowerShell
- Type:
wsl --shutdown - Open the config file:
notepad "$env:USERPROFILE/.wslconfig" - Change settings file & save
- Restart docker desktop
update, after almost 5 hours and after increasing the memory to 7GB, the wsl keeps disconnecting
update, after almost 5 hours and after increasing the memory to 7GB, the wsl keeps disconnecting
Damn it!
I worked for 7h or so and it went well. Did not disconnect! Even suspended and turned it back on. kept running
Something I realized when I increased the memory limit was now it almost doesn't reach the 5gb limit. It stays around 4-4.5. Perhaps your project is consumig more memory than mine. I'd try to remove the memory limit, just to see what happen
update, after almost 5 hours and after increasing the memory to 7GB, the wsl keeps disconnecting
Damn it!
I worked for 7h or so and it went well. Did not disconnect! Even suspended and turned it back on. kept running
Something I realized when I increased the memory limit was now it almost doesn't reach the 5gb limit. It stays around 4-4.5. Perhaps your project is consumig more memory than mine. I'd try to remove the memory limit, just to see what happen
Just updated the configuration with 12GB and yes, i have a lot of process that are running... let's see if this will be enougth
Same problem here. Changing memory configuration did not fix it. Even with 12GB I have disconnections. Quite frustrating.... It's not clear if it depends on WSL, Code plugin or whatever...
Same problem here. Changing memory configuration did not fix it. Even with 12GB I have disconnections. Quite frustrating.... It's not clear if it depends on WSL, Code plugin or whatever...
Well, I'm quite confuse now. After increase memory allocation it's running smoothly. I had no more disconnections.
Other things I'd try to do:
- Disable and enable WSL
- Reinstall remote extensions on vscode.
- Try another linux distro (here I'm using ubunto 20.04)
I'm not sure it would change anything, but I think it's worth it to give it a try.
Although it seems to be solved here, I'll leave this issue open, because you are having problems yet. I hope someone else have another solution.
I am having the same problem and it's causing me to not be able to complete work.
It did this very occasionally for a long time, typically if I ran "go test" in wsl without closing VS Code first.
Now (for the last few weeks, but with increasing frequency this last week) I can't even just do normal go editing for more than 5 minutes without it losing connection (and vmemm being capped out, fans on high, etc.)
I have been relying on WSL2 + VS Code remote to not have to work in a Mac environment for work. Please fix this so that I don't have to deal with MaxOS :)
(For the record, I have 4GB and 2 processors set and it's fine until something background in VS Code starts itself and crushes everything)
I am having the same problem and it's causing me to not be able to complete work.
It did this very occasionally for a long time, typically if I ran "go test" in wsl without closing VS Code first.
Now (for the last few weeks, but with increasing frequency this last week) I can't even just do normal go editing for more than 5 minutes without it losing connection (and vmemm being capped out, fans on high, etc.)
I have been relying on WSL2 + VS Code remote to not have to work in a Mac environment for work. Please fix this so that I don't have to deal with MaxOS :)
(For the record, I have 4GB and 2 processors set and it's fine until something background in VS Code starts itself and crushes everything)
I recommend to increase your memory limit to 5-6gb to try it out. Here I'm using 2-3 NodeJS applications + 2 Docker containers on 5gb memory and 2 cores limit and it's running ok since I increased those.
I bumped it to 12GB, just to give some overhead while looking at how much was being used.
Baseline from Vmmem before VS Code is opened 1,152.0MB Baseline from Vmmem after VS Code is opened but before any editing has occurred is 1,610.0MB Normal editing Go code in VS Code is 3,124.0MB During saves it's hitting just over 4,000MB
Seems like whatever it's doing during save should probably self-abort instead of drop connection if memory gets too tight. (I get that this might be plugins and such as well)
As soon as I start docker, it goes over 6,400MB
A month ago I wasn't having any issue running at 3GB, and now it takes at least 7 to be able to do the same thing. I'm not sure what changed, but please figure it out before I run out of ram to feed to the fire.
And just now when doing normal editing (not running Go test, did have Docker on but no db interactions) it climbed above 8GB and settled back to 6.8GB
I don't think the 12GB is actually going to be enough to prevent the problem, only enough to make it take long enough I can get work done for an hour or two without having to kill processes manually.
And just now when doing normal editing (not running Go test, did have Docker on but no db interactions) it climbed above 8GB and settled back to 6.8GB
I don't think the 12GB is actually going to be enough to prevent the problem, only enough to make it take long enough I can get work done for an hour or two without having to kill processes manually.
For sure it's not normal, 6gb of RAM just to keep the application running, with no interactions. Unfortunally the only thing I can think of is waiting for VSCode to solve this.
Can you run top to see which code process is so memory hungry?
docker is of course pulling a chunk but "node" which is really VS Code is pulling way more than expected

task manager view:

Can you run top -bcn1 -w512 so we can see the command line as well.

After it disconnects, could you try running wsl -l -v and see if the distro is in a 'Running' or 'Stopped' state? It'd be helpful to know if the entire VM is turning off when you're seeing the disconnect or if it's something internal to the VM.
I interpreted "it disconnects" as "'exit' from the wsl2 cli"

It does take a little bit to shut down (about a minute).
It actually disconnects only from vscode remote extension, the WSL keeps going normally
I started seeing this today as well. Everything was working fine yesterday and when I booted up today vscode is disconnecting from wsl immediately. Its able to get the file tree structure then disconnects. WSL is still running. I tried installing older versions and they all have the same issue.
Idk if @msftgits will help us with it.
Since last week I noticed another recurring problem: the internet conection sometimes does not respond. I need do restart the connection adapter to make it work.
It happens always when I suspend the PC and turn back on. Then I need to reset the adapter
I ended up just using the windows filesystem as a work around. I can still use wsl terminals within vscode.
try to disable some vscode plugins in wsl and try, especially TypeScript Importer
Just adding my +1 to this, as the issue has increased frequency over the past few days.
I got the same issue when trying open some .vue files. I have some solutions but it comes with disadvantage
- Delete
.wslconfigthen restart wsl -> But sometimewmmemis using too much memory - Disabled
Veturextension (or I guess, extension which related tojstyping) -> it makes myvuefiles look so bad and I cannot detect syntax errors
I got it fixed by installing VS Code Insiders a couple weeks ago, but since 2 weeks it keeps happening again. VS Code + WSL2 is unusable for me because it starts the reconnect loop immedtiately and only thing I can do is save files but most extensions don't really work since they just hang. Not even autocomplete works.

For me, it was due to the C# extension, powered by Omnisharp, which was using a significant amount of memory causing an OOM.