-
Notifications
You must be signed in to change notification settings - Fork 320
Connection unaware of reboots/graceful disconnect #9117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Thanks for sharing these details. Just to clarify - which remote extension(s) are you using? |
No specific extensions. This is about the behavior of remote connections in general |
I'm a little confused what you're asking here. If you've rebooted your remote host, how would VS Code know that? From ssh's perspective, didn't the host just go offline (which perhaps also happened due to flakey internet, which is why a reconnect would be preferred)? Could you disconnect from your remote host before rebooting it? |
It is not about the VScode server knowing if the reason was a reboot, that is of course not possible as it would be killed by the remote host before it could even notify of that. The SSH connection will be disconnected by the remote host though, that is something that can be caught by the SSH client on the local host. Either by catching the ssh host closing the pipe or if that was missed via a keep-alive timeout like most SSH clients implement. There are two connected issues that I am experiencing. The first is that sometimes the local VScode instance does not give up on a broken connection/pipe at all, e.g. the reconnect timeout setting seems to do nothing and I have to close VScode and re-open it to resume. Then secondly, the time it takes to reconnect to an alive host is generally very long. I can be reconnected to the host with my SSH session on the terminal for over a minute and VScode is still trying to use the old pipe until it eventually determines that it won't try again and then does the pop-up where it asks if it should reconnect, which restores my connection on a new pipe. The latter is the the behavior I would like to have but without the possible endless spiral or the long delay of trying to re-use the pipe it was connected to before. This is something that does not heavily affect typical server work where you rarely reboot but when working on remote embedded Linux systems f.e. where you need to frequently reboot to apply a kernel level change, this can quickly become very tedious. E: Closing the connection manually is not really a good solution as that means closing the entire window which is what I would like to avoid to constantly restart VScode and reconnect to a client going through the full connection flow again. |
Hey @connor4312 @joshspicer, this issue might need further attention. @timonsku, you can help us out by closing this issue if the problem no longer exists, or adding more information. |
This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines. Happy Coding! |
Informationen was provided. Not sure why this got auto closed? |
Type: Bug
When rebooting a Linux remote host, VSCode does not seem to be aware of that and tries to reconnect to the session.
Which would be wanted behaviour but it never manages to reconnect once the host is back up and you need to wait until VSCode fails completely and offer the option to reload the window.
This process does not seem to be affected at all by the settings for reconnect timeouts and attempts and can last very long in some instances.
Expected behaviour would be to be aware of the system reboot and reopen a new socket once the host is available again. It seems right now it gets stuck in trying to reuse the old connection.
Extension version: 0.106.5
VS Code version: Code 1.83.1 (f1b07bd25dfad64b0167beb15359ae573aecd2cc, 2023-10-10T23:48:05.904Z)
OS version: Windows_NT x64 10.0.19045
Modes:
Remote OS version: Linux arm64 6.1.58-v8+
System Info
canvas_oop_rasterization: enabled_on
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
video_decode: enabled
video_encode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled
webgpu: enabled
A/B Experiments
The text was updated successfully, but these errors were encountered: