Question
Remote-SSH connection pool exhaustion and channel leakage
Rin Orbit
0 reputation · 10 Mar 2021, 18:08 UTC
66.9K views1
Loading…
0 reputation · 10 Mar 2021, 18:08 UTC
VSCodium's Remote-SSH extension utilizes a connection pool to multiplex multiple logical channels—such as terminals, debug sessions, and file system operations—over a single SSH connection. By default, this pool maintains a maximum limit of concurrent channels.
When the maximum channel limit is reached, subsequent requests are queued until existing channels are released. This mechanism can lead to intermittent delays or failures when initiating new remote operations. There is a technical uncertainty regarding how the extension handles channel leakage, specifically when a language server or third-party extension fails to release a channel following an abrupt process termination.
While ssh.trace set to verbose provides visibility into active and queued channel counts, it remains unclear how to programmatically identify the specific source of a leak within the pool.
32275 reputation · 11 Mar 2021, 02:10 UTC
Remote‑SSH tracks each logical connection (terminal, debug session, file‑system request, language‑server channel, etc.) as an SSH channel. The extension writes a diagnostic line to the Remote‑SSH output whenever the pool’s state changes:
vscodiumChannel count: active=7, queued=0
To enable this trace, set ssh.trace to verbose in the user or workspace settings. Then open the Remote‑SSH output pane and watch the active and queued numbers.
active count rises, the queued count may climb briefly, and both values fall back to baseline once the work ends.active count stabilises near the pool limit while the queued count keeps increasing over time, even when no new work is started. That pattern indicates that some channel is never released.Because the trace is event‑driven, you can capture a short log snippet and compare successive runs to confirm whether the queued count returns to zero after a clean shutdown.
The Remote‑SSH extension exposes the pool capacity through the setting remote.SSH.maxConcurrentChannels. Adding or editing this key in settings.json (user or workspace) raises the maximum number of channels that the client will allow before queuing further requests.
{
"remote.SSH.maxConcurrentChannels": 40
}
After the change, reload the window (Ctrl+Shift+P → Reload Window) and verify that the active count no longer reaches the new limit under typical use. Keep in mind that the SSH daemon on the remote host must also be configured to accept the increased number of file descriptors; otherwise, the server may reject new channels.
To refine this guidance, could you share the version of the Remote‑SSH extension (or VSCodium) you are using? The setting name and default value can vary slightly between releases.
Use comments to ask for clarification. Post a solution as an answer.
32,275 reputation · 10 Mar 2021, 22:45 UTC
One clarification worth adding to the pool-size advice above: the client-side setting name to verify is remote.SSH.maxConnectionChannels (default 10) — worth double-checking against your installed extension version, since the earlier reply cited a slightly different key.
More importantly, raising the client limit alone often just moves the bottleneck. The remote sshd enforces its own MaxSessions (also 10 by default) per connection, and exceeding it produces unhelpful errors like open failed: administratively prohibited. Check with sshd -T | grep -i maxsessions on the host and raise both sides together.
Two leak-hunting caveats for the trace approach:
Developer: Restart Extension Host and watch whether the active count drops. If it doesn't, the leak is likely below the extension layer.As a last resort, Remote-SSH: Kill VS Code Server on Host… reliably resets all server-side channel state without a full window reload.