search

jeanp413 / open-remote-wsl

VSCode Remote Development: Open any folder in the Windows Subsystem for Linux (WSL).
MIT License
22 stars 3 forks source link

Issue with WSL losing remote connection randomly - Cannot reconnect. Please reload the window #2

Open PylotLight opened 1 year ago

PylotLight commented 1 year ago

Having issues with the extension losing connection randomly, not sure where to find any logs for this issues. So far after testing, downloading the original WSL extension vsix, does not have the same timeout issue, so should be related to this extension I think.

2023-09-09 12:35:26.139 [info] [remote-connection][ExtensionHost][7c117…][reconnect] received socket timeout event (unacknowledgedMsgCount: 523, timeSinceOldestUnacknowledgedMsg: 1654689, timeSinceLastReceivedSomeData: 1658676). 2023-09-09 11:57:57.775 [error] Missing 'tunnelApplicationConfig' or 'tunnelApplicationName' in product.json. Remote tunneling is not available image

jeanp413 commented 1 year ago

Hi @PylotLight I can repro with vscodium 1.82.0, but it works fine with 1.81.1, in the meantime you can downgrade vscodium Will take a deeper look, not sure what have changed in the latest stable release that causes this disconnection

PylotLight commented 1 year ago

If you prove it's purely vscodium issue then feel free to close but given there's no issues with the official extension there must be something different, I imagine would be hard to resolve given the closed source nature, but ye hopefully its fixable.

jeanp413 commented 1 year ago

Actually I only could repro once, the first time I updated to 1.82, after downgrade to 1.81 and then update back to 1.82 I can't repro anymore 🤔 Does it happen for you consistently? Which WSL distro are you using? Is it wsl 1 or wsl 2? Also when it happens again, please share logs from window in output panel and logs from vscodium server in ~/.vscodium-server/.13ae69686c4390a9aee7b71b44337eb488319f26.log inside WSL image

PylotLight commented 1 year ago

I have left the connection open for several minutes at this point without a repeat of the error after I reinstalled the extension so will have to keep testing and monitoring. Perhaps we close for now and I'll report back with requested logs and reopen if the issue returns.

2023-09-09 18:00:05.907 [info] [LocalProcess0][resolveAuthority(wsl,1)][16005ms] waiting... 2023-09-09 18:00:06.430 [info] [LocalProcess0][resolveAuthority(wsl,1)][16529ms] returned WebSocket(127.0.0.1:51235) 2023-09-09 18:00:06.430 [info] resolveAuthority(wsl) returned 'WebSocket(127.0.0.1:51235)' after 16530 ms 2023-09-09 18:00:06.431 [info] Creating a socket (renderer-Management-b88d0779-524f-4882-942e-ecc741c04c2b)... 2023-09-09 18:00:06.432 [info] Creating a socket (renderer-ExtensionHost-517895a4-6bbf-485a-b603-c4995472519f)... 2023-09-09 18:00:06.897 [info] Creating a socket (renderer-Management-b88d0779-524f-4882-942e-ecc741c04c2b) was successful after 466 ms. 2023-09-09 18:00:07.036 [info] Creating a socket (renderer-ExtensionHost-517895a4-6bbf-485a-b603-c4995472519f) was successful after 602 ms. 2023-09-09 18:00:08.870 [info] [perf] Render performance baseline is 30ms 2023-09-09 18:01:30.481 [error] semantictokens are disabled: Error: semantictokens are disabled

It's WSL2 using Debian. Btw being able to open with distro option would be highly valuable, but there is a way around it for now as currently it just uses default distro which may or may not be the one we want to launch with.

image

PylotLight commented 1 year ago

Repeated the issue on my work machine now:

2023-09-11 11:10:39.336 [info] Creating a socket (renderer-Management-901f0967-2161-4294-be99-6e6bc8f918a5) was successful after 6 ms. 2023-09-11 11:10:39.353 [info] Creating a socket (renderer-ExtensionHost-873325fc-630f-4194-b537-47fd766b3afb) was successful after 23 ms. 2023-09-11 11:10:40.741 [info] [perf] Render performance baseline is 35ms 2023-09-11 11:19:57.667 [info] [remote-connection][ExtensionHost][87332…][reconnect] received socket close event (wasClean: false, code: 1006, reason: ). 2023-09-11 11:19:57.667 [error] {"isTrusted":true} 2023-09-11 11:19:57.668 [info] [remote-connection][ExtensionHost][87332…][reconnect] starting reconnecting loop. You can get more information with the trace log level. 2023-09-11 11:19:57.668 [info] [remote-connection][ExtensionHost][87332…][reconnect] resolving connection... 2023-09-11 11:19:57.668 [info] [remote-connection][ExtensionHost][87332…][reconnect] connecting to WebSocket(127.0.0.1:37209)... 2023-09-11 11:19:57.668 [info] Creating a socket (renderer-ExtensionHost-873325fc-630f-4194-b537-47fd766b3afb)... 2023-09-11 11:19:57.689 [info] [remote-connection][Management ][901f0…][reconnect] received socket close event (wasClean: false, code: 1006, reason: ). 2023-09-11 11:19:57.689 [error] {"isTrusted":true} 2023-09-11 11:19:57.689 [info] [remote-connection][Management ][901f0…][reconnect] starting reconnecting loop. You can get more information with the trace log level. 2023-09-11 11:19:57.691 [info] [remote-connection][Management ][901f0…][reconnect] resolving connection... 2023-09-11 11:19:57.691 [info] Invoking resolveAuthority(wsl)... 2023-09-11 11:19:57.691 [info] [LocalProcess0][resolveAuthority(wsl,2)][0ms] obtaining proxy... 2023-09-11 11:19:57.691 [info] [LocalProcess0][resolveAuthority(wsl,2)][0ms] invoking... 2023-09-11 11:19:57.695 [info] Creating a socket (renderer-ExtensionHost-873325fc-630f-4194-b537-47fd766b3afb) returned an error after 27 ms. 2023-09-11 11:19:57.695 [error] CodeExpectedError: WebSocket close with status code 1006

jeanp413 commented 1 year ago

Current logs tell that the connection got closed for some reason, server logs should be more useful, when it happens again could you share server logs from ~/.vscodium-server/.13ae69686c4390a9aee7b71b44337eb488319f26.log inside WSL distro :pray:

I can repro now, will work on a fix.

PylotLight commented 1 year ago

Just to make sure you have my example, heres some of my server logs; [12:33:14] Error: Throttler is disposed 0400 at l.queue (/home/user/.vscodium-server/bin/13ae69686c4390a9aee7b71b44337eb488319f26/out/vs/server/node/server.main.js:70:16246) 0400 at /home/user/.vscodium-server/bin/13ae69686c4390a9aee7b71b44337eb488319f26/out/vs/server/node/server.main.js:70:18427 0400 at /home/user/.vscodium-server/bin/13ae69686c4390a9aee7b71b44337eb488319f26/out/vs/server/node/server.main.js:70:17883 0400 at runNextTicks (node:internal/process/task_queues:60:5) 0400 at listOnTimeout (node:internal/timers:538:9) 0400 at process.processTimers (node:internal/timers:512:7) [12:33:14] Error: Throttler is disposed 0400 at l.queue (/home/user/.vscodium-server/bin/13ae69686c4390a9aee7b71b44337eb488319f26/out/vs/server/node/server.main.js:70:16246) 0400 at /home/user/.vscodium-server/bin/13ae69686c4390a9aee7b71b44337eb488319f26/out/vs/server/node/server.main.js:70:18427 0400 at /home/user/.vscodium-server/bin/13ae69686c4390a9aee7b71b44337eb488319f26/out/vs/server/node/server.main.js:70:17883 0400 at runNextTicks (node:internal/process/task_queues:60:5) 0400 at listOnTimeout (node:internal/timers:538:9) 0400 at process.processTimers (node:internal/timers:512:7) [12:33:14] [127.0.0.1][6433e02c][ExtensionHostConnection] <25443> Extension Host Process exited with code: 0, signal: null. Cancelling previous shutdown timeout [12:33:14] Cancelling previous shutdown timeout 4300 Last EH closed, waiting before shutting down [12:33:14] Last EH closed, waiting before shutting down 4300 Last EH closed, shutting down [12:38:14] Last EH closed, shutting down

GitMensch commented 1 year ago

I can repro now, will work on a fix.

Yay (this affects me, a first time-user of Open Remote WSL, too; at least on earlier versions the manual "start ssh server, get ip, connect via your SSH extension" did work without any aborts; but the nice integration of Open Remote WSL is really good!)

informeti commented 11 months ago

The issue exists in 1.83.1 as well:

Version: 1.83.1
Release: 23285
Commit: 36d13de33ac0d6c684f10f99cff352e2f58228b3
Date: 2023-10-12T18:42:10.077Z
Electron: 25.8.4
ElectronBuildId: undefined
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Windows_NT x64 10.0.19045
Moortu commented 11 months ago

I've been having this as well

jeanp413 commented 11 months ago

I know the reason but been short of time lately to work on this, I'll see if have some time this month :pray:

subnut commented 11 months ago

~Current logs tell that the connection got closed for some reason, server logs should be more useful, when it happens again could you share server logs from ~/.vscodium-server/.13ae69686c4390a9aee7b71b44337eb488319f26.log inside WSL distro 🙏~

I can repro now, will work on a fix.

~It's impossible to fetch the ~/.vscodium-server/.*.log file after a crash because it immediately gets truncated by the output of the restarted server.... is there any way to ensure that the server doesn't restart by itself?~

nvm i just created a hardlink to the file... that way i still got the old logs.

...Also, pls fix ASAP if possible...thanks!

subnut commented 11 months ago

Or you could tell me in short what's causing it... and I could try looking into how to fix it...

I'm relatively free till this weekend...

PylotLight commented 11 months ago

From what I'm seeing in these logs there seems to be 2 issues.

  1. The WS connection gets a received socket close event
  2. Failure to reconnect upon getting that close event. Error: Connection error: Unknown reconnection token (never seen) - permanent failure occurred while running the reconnecting loop. - received socket timeout event image
jeanp413 commented 10 months ago

Let me explain the issue:

PylotLight commented 10 months ago

This confuses me slightly as I get errors on just 1 window, after opening vscodium and touching nothing else, what do you mean 2+ windows? image

jeanp413 commented 10 months ago

what do you mean 2+ windows?

At least two vscode windows connected to the same WSL distro, only one will start the vscode server, so if that window is closed then the other vscode window connected to the same server will disconnect as there's no server running.

@PylotLight in your case if you only have one window, do you see a pattern? does it happen after an update or after a window reload?

PylotLight commented 10 months ago

At least two vscode windows connected to the same WSL distro

As shown in my pic, I was getting the disconnect error with no other windows open, so I've seen this issue occur in various senarios, e.g where I would open codium, do nothing, leave it for a few minutes and it would just disconnect on its own.

And other cases where I have a spilt view which I assume counts as two windows which works fine for hours with no issues.

@PylotLight in your case if you only have one window, do you see a pattern? does it happen after an update or after a window reload?

Unfortunately I don't have any patterns to report at this time, is there any way we could add extra logging into the extension to try narrow down some issues to provide better feedback? Perhaps an alternative version could be used?

orariley70 commented 10 months ago

Hello @PylotLight. Glad seeing that you're not the only one that has this problem. It does seem harmless, but a pretty annoying bug every couple of minutes. I can repro as well.

PylotLight commented 10 months ago

Hello @PylotLight. Glad seeing that you're not the only one that has this problem. It does seem harmless, but a pretty annoying bug every couple of minutes. I can repro as well.

The question is can you repro consistently? I do often get the issue, but sometimes its fine and sometimes it's not, I haven't figured out a pattern for it.

orariley70 commented 10 months ago

It will do it after a certain minutes of usage. Doesn't care if there's anything or nothing going on. I had this happen when there's a process running on the terminal or when I'm editing. I know, it isn't really helpful.

orariley70 commented 10 months ago

I realized when the host VSCodium says it's disconnected, the server will have different PIDs like it was restarting itself, but I can't find any relevant log (lines). When server (re)starts, it overwrites the log instantly.

subnut commented 10 months ago

When server (re)starts, it overwrites the log instantly

That was the exact same problem when I was trying to debug this issue.

You could try creating a hard link to the log file, with a different name using the ln command... eg

ln logfile logfile2

Then, after the server restarts, theoretically you could get the older logs in logfile2.

HTGAzureX1212 commented 10 months ago

Greetings, I have also encountered this issue today. Indeed this is quite annoying.

Please see the console logs below, from within DevTools: image

This happens when I only have one VSCodium window open.

ColorfulRhino commented 9 months ago

I believe this issue is gone for me since I switched to WSL Kernel 6.1.

Can anyone else try and confirm?

Here are instructions on how to do use the new kernel: https://learn.microsoft.com/en-us/community/content/wsl-user-msft-kernel-v6

PylotLight commented 9 months ago

I've also compiled and upgraded, will leave this comment here and update it if I have any errors. Status: Still getting errors on work machine, and home machine unfortunately.

P.S MS docs suck and defs required some extra not included steps.

entepe85 commented 8 months ago

Yeah, the documentation from MS definitely fails to mention that on distros other than Ubuntu (using Debian 12 here) some packages like bc could be missing and causing the kernel build to fail. Moreover, copying to /mnt/c/ isn't working and the Windows Explorer must be used to copy the bzImage file. But I digress...

@ColorfulRhino - Since I updated the WSL kernel to 6.1 the issue hasn't reappeared.

ColorfulRhino commented 8 months ago

I still get the "Please reconnect" sometimes with kernel 6.1, but rarely compared to before with kernel 5.15. It's definitely managable with 6.1

brandochn commented 7 months ago

The same issue here:

Version: 1.87.2 (system setup) Release: 24072 Commit: f7ed6417a7cfae92f98129384c13b505bb9cfc53 Date: 2024-03-12T18:37:03.663Z Electron: 27.3.2 ElectronBuildId: undefined Chromium: 118.0.5993.159 Node.js: 18.17.1 V8: 11.8.172.18-electron.0 OS: Windows_NT x64 10.0.19045

I am using WSL2 with Ubuntu Preview.

Morpheus0x commented 7 months ago

Also experiencing the same issue on Windows 10 (22H2 19045.4170) with latest VSCodium 1.88.1.24104 and WSL 2.0 Debian 10 (Kernel: 5.15.150.1-microsoft-standard-WSL2). I have only a single VSCodium window open connected to the only installed WSL distro with a Workspace opened at /mnt/c/Users/...

I noticed the issue when the VSCodium window is open on my second monitor but not focused, or when unlocking windows after coming back from a coffee break. The second one isn't a big deal since I just need to reload to continue, but having to do this every time switching back to the editor when researching something is annoying. Edit: This also happens when the window is focused and I am actively working on a file

VSCodium Window Log Output for Error (Trace log level):

2024-04-23 14:54:50.146 [info] [remote-connection][ExtensionHost][2247b…][reconnect] received socket close event (wasClean: false, code: 1006, reason: ).
2024-04-23 14:54:50.146 [error] {"isTrusted":true}
2024-04-23 14:54:50.147 [info] [remote-connection][ExtensionHost][2247b…][reconnect] starting reconnecting loop. You can get more information with the trace log level.
2024-04-23 14:54:50.147 [info] [remote-connection][ExtensionHost][2247b…][reconnect] resolving connection...
2024-04-23 14:54:50.148 [info] [remote-connection][ExtensionHost][2247b…][reconnect] connecting to WebSocket(127.0.0.1:38469)...
2024-04-23 14:54:50.148 [trace] [remote-connection][ExtensionHost][2247b…][reconnect][WebSocket(127.0.0.1:38469)] 1/6. invoking socketFactory.connect().
2024-04-23 14:54:50.148 [info] Creating a socket (renderer-ExtensionHost-2247b5dd-fd0b-42c5-8f0d-24542ad7e76b)...
2024-04-23 14:54:50.205 [info] [remote-connection][Management   ][e7210…][reconnect] received socket close event (wasClean: false, code: 1006, reason: ).
2024-04-23 14:54:50.206 [error] {"isTrusted":true}
2024-04-23 14:54:50.206 [info] [remote-connection][Management   ][e7210…][reconnect] starting reconnecting loop. You can get more information with the trace log level.
2024-04-23 14:54:50.207 [info] [remote-connection][Management   ][e7210…][reconnect] resolving connection...
2024-04-23 14:54:50.208 [info] Invoking resolveAuthority(wsl)...
2024-04-23 14:54:50.208 [info] [LocalProcess0][resolveAuthority(wsl,2)][0ms] obtaining proxy...
2024-04-23 14:54:50.209 [info] [LocalProcess0][resolveAuthority(wsl,2)][0ms] invoking...
2024-04-23 14:54:50.219 [info] Creating a socket (renderer-ExtensionHost-2247b5dd-fd0b-42c5-8f0d-24542ad7e76b) returned an error after 71 ms.
2024-04-23 14:54:50.219 [error] CodeExpectedError: WebSocket close with status code 1006
    at WebSocket.<anonymous> (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:688:4976)
2024-04-23 14:54:50.219 [error] [remote-connection][ExtensionHost][2247b…][reconnect][WebSocket(127.0.0.1:38469)] socketFactory.connect() failed or timed out. Error:
2024-04-23 14:54:50.220 [error] CodeExpectedError: WebSocket close with status code 1006
    at WebSocket.<anonymous> (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:688:4976)
2024-04-23 14:54:50.220 [info] [remote-connection][ExtensionHost][2247b…][reconnect] A temporarily not available error occurred while trying to reconnect, will try again...
2024-04-23 14:54:50.220 [trace] WebSocket close with status code 1006: CodeExpectedError: WebSocket close with status code 1006
    at WebSocket.<anonymous> (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:688:4976)
2024-04-23 14:54:50.221 [info] [remote-connection][ExtensionHost][2247b…][reconnect] waiting for 5 seconds before reconnecting...
2024-04-23 14:54:51.075 [info] [LocalProcess0][resolveAuthority(wsl,2)][867ms] returned WebSocket(127.0.0.1:46507)
2024-04-23 14:54:51.075 [info] resolveAuthority(wsl) returned 'WebSocket(127.0.0.1:46507)' after 868 ms
2024-04-23 14:54:51.076 [info] [remote-connection][Management   ][e7210…][reconnect] connecting to WebSocket(127.0.0.1:46507)...
2024-04-23 14:54:51.076 [trace] [remote-connection][Management   ][e7210…][reconnect][WebSocket(127.0.0.1:46507)] 1/6. invoking socketFactory.connect().
2024-04-23 14:54:51.076 [info] Creating a socket (renderer-Management-e7210d8e-23dd-49b6-b481-a6aa5f4d188a)...
2024-04-23 14:54:51.590 [info] Creating a socket (renderer-Management-e7210d8e-23dd-49b6-b481-a6aa5f4d188a) was successful after 514 ms.
2024-04-23 14:54:51.590 [trace] [remote-connection][Management   ][e7210…][reconnect][WebSocket(127.0.0.1:46507)] 2/6. socketFactory.connect() was successful.
2024-04-23 14:54:51.590 [trace] [remote-connection][Management   ][e7210…][reconnect][WebSocket(127.0.0.1:46507)] 3/6. sending AuthRequest control message.
2024-04-23 14:54:51.598 [trace] [remote-connection][Management   ][e7210…][reconnect][WebSocket(127.0.0.1:46507)] 4/6. received SignRequest control message.
2024-04-23 14:54:51.601 [trace] [remote-connection][Management   ][e7210…][reconnect][WebSocket(127.0.0.1:46507)] 5/6. sending ConnectionTypeRequest control message.
2024-04-23 14:54:51.603 [info] [remote-connection][Management   ][e7210…][reconnect] received socket close event (wasClean: false, code: 1006, reason: ).
2024-04-23 14:54:51.603 [error] {"isTrusted":true}
2024-04-23 14:54:51.604 [error] [remote-connection][Management   ][e7210…][reconnect][WebSocket(127.0.0.1:46507)] received error control message when negotiating connection. Error:
2024-04-23 14:54:51.604 [error] Error: Connection error: Unknown reconnection token (never seen)
    at G (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:688:22436)
    at u.value (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:688:12069)
    at n._deliver (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:89:837)
    at n.fire (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:89:1156)
    at s.fire (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:628:17272)
    at l._receiveMessage (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:628:22215)
    at u.value (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:628:21186)
    at n._deliver (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:89:837)
    at n.fire (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:89:1156)
    at c.acceptChunk (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:628:14096)
    at vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:628:13226
    at u.value (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:688:6052)
    at n._deliver (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:89:837)
    at n.fire (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:89:1156)
    at _fileReader.onload (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:688:4102)
2024-04-23 14:54:51.604 [error] [remote-connection][Management   ][e7210…][reconnect] A permanent error occurred in the reconnecting loop! Will give up now! Error:
2024-04-23 14:54:51.604 [error] Error: Connection error: Unknown reconnection token (never seen)
    at G (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:688:22436)
    at u.value (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:688:12069)
    at n._deliver (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:89:837)
    at n.fire (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:89:1156)
    at s.fire (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:628:17272)
    at l._receiveMessage (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:628:22215)
    at u.value (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:628:21186)
    at n._deliver (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:89:837)
    at n.fire (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:89:1156)
    at c.acceptChunk (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:628:14096)
    at vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:628:13226
    at u.value (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:688:6052)
    at n._deliver (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:89:837)
    at n.fire (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:89:1156)
    at _fileReader.onload (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:688:4102)
2024-04-23 14:54:51.605 [trace] DialogService#confirm Cannot reconnect. Please reload the window.
2024-04-23 14:54:53.647 [info] Extension host (Remote) is unresponsive.
PylotLight commented 7 months ago

Attempting to dig into the code which is way out of my wheelhouse: This didn't work and defs broke things. const cmd = cp.spawn(wslBinary, args, { windowsHide: true, windowsVerbatimArguments: true, detached: true });

Also a child process already seems to be calling wsl commands so I feel like the earlier suggestion doesn't quite make sense. Finding where the socket management is done is a bit confusing as there's likely a lot happening on the vsce side that we can't see.

CompeyDev commented 7 months ago

As a workaround, you can manually launch the server on the WSL instance.

Simply navigate to $HOME/.vscodium-server/bin/{{VERSION_HASH}}/bin on the WSL machine and call ./codium-server. You can find your version hash in VSCodium in help > about > commit.

sneakylenny commented 6 months ago

Workaround

A good work around is to:

  1. Close all Codium windows
  2. Run htop in wsl (or any other task manager)
  3. Kill the vscode server process (/home/<username>/.vscodium-server/...)
  4. ...
  5. PROFIT $$$

All jokes aside, when you follow these steps you'll be able to use Codium without having to "reload window" every 10 minutes or so.

entepe85 commented 6 months ago

Unfortunately, this issue still persists on the most recent WSL2 kernel under certain circumstances, e.g. reconnecting after opening a different workspace.

While the workaround might be feasible it's potentially less effort to start the remote extension host (i.e. vscodium-server) in a detached shell in the WSL2 and connecting manually.

ubidev commented 5 months ago

Hi! I just started using that extension and have the same problem alas on latest w11 enterprise 23h2 latest build image image

GitMensch commented 5 months ago

@entepe85 wrote:

While the workaround might be feasible it's potentially less effort to start the remote extension host (i.e. vscodium-server) in a detached shell in the WSL2 and connecting manually.

How would you exactly do that? I guess you would connect once with this extension to have the server installed and after first disconnect do ???

CompeyDev commented 5 months ago

I guess you would connect once

That's correct - you would need to initially set the extension up, or download the codium-reh from GitHub releases for VSCodium.

PylotLight commented 5 months ago

I've found what works for me is just using wsl --shutdown to restart the whole session which makes it work for a while fixing whatever is broken in the background.