Port proliferation while remote debugging -- kills remote server! #169182
Comments
|
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.74.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding! |
|
I updated to v1.74.1 and repeated the experiment -- the issue was even worse. After closing the React App, there were 114 ports left in "TIME-WAIT": |
|
VS Code just now now killed the remote server again. I understand that bugs happen (I've been a professional developer for decades). The fact that VS Code renders the remote server inaccessible is a major issue. I can't tell if the remote server has actually crashed or if VS Code has destroyed its ability to handle SSH connections. I can provide |
|
I know it's late Friday, but has there been any progress on this? I'm not sure yet whether this is from simply connecting VS Code or the result of some change in the javascript/nodejs support. What I do know is that it is happening MUCH more frequently. I basically have to wait at least minute after every user gesture (mouse click, etc) in order to avoid killing the server. One of the immediate symptoms is that VS Code itself hangs while trying to reconnect to its remote server. I'm seeing many (often tens) of "TIME-WAIT" ports happening in response to events while running the Javascript debugger. These ports seem to clear after a timeout of 1.0-1.5 minutes. The server will sometimes become accessible again if I wait long enough. I just now had to reboot the server because saving a change while the debugger was active provoked this while the debugger was trying to compile the changes. I'm happy to provide any further information that might be helpful, just let me know. |
|
Is anything happening on this? I've just had to reboot the target system again. Whatever is causing this makes VSCode unusable. This is a show-stopper. |
A debt item I've been meaning to address for a while anyway. Though we still want to support port servers for VS debug. Should fix microsoft/vscode#169182
A debt item I've been meaning to address for a while anyway. Though we still want to support port servers for VS debug. Should fix microsoft/vscode#169182
|
Pardon the pestilent port proliferation. I've improved things in the linked PR (which is also an improvement I've meant to make for a while), though there is still some port usage for browser connections. I think this should be the bulk of it, though, since all other traffic to the local browser goes through a single socket. It is correct that TIME_WAIT ports should cleared up by the system after a configured timeout. You can reduce this by setting |
connor4312
added
debug
A debt item I've been meaning to address for a while anyway. Though we still want to support port servers for VS debug. Should fix microsoft/vscode#169182
|
I appreciate your attention, especially this week. As I've dealt with this more often, it appears that these hundreds of ports are somehow choking access to the server. It may even be on my end (the connectivity is still a bit of a mystery to me). I do all my development on a target system that is a robust AWS EC2 instance running a current version of Rocky Linux. My local system is robust physical system running a current version of Rocky Linux with a Windows 10 Pro guest VM running on VirtualBox. There are therefore several layers of abstraction at play. I use "SecureCRT" to provide my SSH client connections to the world. This is running on my local system. I usually (but not always) have one or two SSH shell connections from my local system to the target system while I'm doing active development. When this problem occurs, any connected shells are unresponsive and I'm unable to open any new connections to the server. The server itself is still running -- it appears that there is some implicit or explicit limit on the number of ports available. After a timeout period of what appears to be a few minutes, the TIME_WAIT ports disappear and I regain connectivity. In any case, reducing the number of TIME_WAIT ports is likely to help -- and I appreciate this fix. |
|
Thanks for the info. Please let me know if you continue to hit this. You'll be able to try out the nightly build in about 2 hours (note that it should get installed on the remote machine to take effect for this case) |
|
Is this ever going to be fixed in the mainline? I'm reluctant to switch to the nightly build. This seems to be very invasive to VSC, and it's already fragile. I'm still seeing the issue. When it happens, I'm locked out of the remote system -- ALL connections -- for at least minutes. I even wonder if it's triggering some sort of AWS security protocol. At times, I have to reboot the remote server to get things working properly again. Here is the "About" text from my current version: |
|
This bug killed my access to the remove server more than 20 minutes ago -- plenty of time for TIME_WAIT ports to clear. In order to recover from this, I need to:
This is specific to VSCode -- I experience no such issues when running the same code from an SSH command line connected to the remove server ( Please let me know if there is instrumentation I can add or log files I can provide that will assist in fixing this issue. |
|
As is tradition, we skipped the end of December release for the holidays; the next stable VS Code release is happening next week. |
|
Two questions:
|
|
|
Got it, I appreciate the quick response. I'll try the nightly build and see if things improve. Is there anything in One thing I notice is that AWS apparently refreshes its private IP lease every halfhour: The timestamp of this entry corresponds to when I saw the most recent failure: I don't know what "nss" is and I don't know what "own WATCHDOG" means. The following entry corresponds to when connectivity was re-established about 30 minutes later: Is there something in VSCode that is creating issues with |
|
I experienced another lockout just now. Here is the relevant excerpt from I noticed the failure at 19:23, coincident with the following log entry (from above): |
Even a brief debugging session using VS Code on a robust AWS EC2 instance running Rocky Linux 8.6 causes a proliferation of "TIME-WAIT" ports -- I counted 89 after the brief session described below.
The result is that the target system frequently becomes inaccessible (I can't tell whether it runs out of memory, runs out of ports, or something else happens). The result is that I have to restart the target system from the AWS EC2 console.
This happens much more frequently now than it did a few months ago.
Type: Bug
VS Code version: Code 1.74.0 (5235c6b, 2022-12-05T16:38:16.075Z)
OS version: Windows_NT x64 10.0.18363
Modes:
Sandboxed: No
Remote OS version: Linux x64 4.18.0-425.3.1.el8.x86_64
Remote OS version: Linux x64 4.18.0-372.32.1.el8_6.x86_64
System Info
canvas_oop_rasterization: disabled_off
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: unavailable_off
raw_draw: disabled_off_ok
skia_renderer: enabled_on
video_decode: enabled
video_encode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled
webgpu: disabled_off
Extensions (4)
The text was updated successfully, but these errors were encountered: