Allow session detach & re-attach over long periods of time

[tariqrafique]

I connect to a physical linux host using vscode remote ssh.

I end up opening a bunch of terminals in vscode.

When I leave disconnect from the network / leave for the day, my terminal contents are completely lost. I have to restart all the processes.

Would it be possible to leave the remote session running along with it's terminal processes even if the client is disconnected.

When the client reconnects, just re-attach to the terminals that were started previously

Thanks!

[roblourens]

We do allow this, but only over a few hours, not the next day. The reason is that the remote terminals and extensions can take up a lot of resources, and we don't know for sure whether you are done with them or not. You might consider using tmux to persist your terminal sessions on the remote outside of vscode, this is what I do.

[tariqrafique]

@roblourens I don't see this happening even if I disconnect and immediately re-connect

[tariqrafique]

can vs-code not provide an explicit option to detach and re-attach to the session ?

[roblourens]

If you explicitly disconnect (by closing the window or running the disconnect command or something) then your session on the other side will not be preserved.

I don't want to make this a feature request for explictly preserving sessions because I think the only place in the remote EH where state really matters is in terminals, and there are already tools that do a good job with this.

[vadimcn]

@roblourens

and there are already tools that do a good job with this.

Can you please share which ones work the best and how to configure VSCode terminal to use them?
I once tried using tmux to solve this problem, but it does not integrate well with the native terminal scroll buffer nor with multi-terminal sessions.

Also, terminal is not the only stateful feature of VSCode: sometimes I start a long-running process under a debugger, and disconnecting kills debug sessions.

[roblourens]

I am thinking of tmux. I guess I can leave this open as a feature request, it might be nice to have a session manager and let the user explicitly persist and reattach to sessions.

[gunn]

@roblourens In my use-case I don't care about using server resources, but really want to avoid long "Setting up SSH remote" wait times, and ideally avoid "Could not establish connection" prompts when the connection breaks.

Can tmux help with this? If so what does configuring it for VS Code look like? I tried using byobu and it works properly for maintaining sessions when connecting from Terminal.app, but does nothing for VS Code remote sessions.

[roblourens]

You can set up tmux so your terminal sessions will be persisted across connections, but vscode will still have to reconnect.

[gunn]

@roblourens Connecting / reconnecting to a remote server with vscode takes a long time relative to either open a local project in vscode, or connecting to a server with ssh. Can something be done to help this?

[roblourens]

You can enable remote.SSH.useLocalServer which will share connections between windows and make new connections after the first one faster. May or may not help with your use case.

It's enabled by default in the nightly version of the extension.

[kaspernj]

I am having the same issue. Leaving the editor for a couple of hours will reset my workspace. The interesting part is that it will keep the Ruby on Rails server running + Webpack development server, so I have to go in kill the old processes before I can start them up again.

While it is possible to do so, it is very cumbersome (especially because I have to do it multiple times per day).

The machines I am using are dedicated development servers with i9 CPU's and 64 GB RAM, so leaving the processes hanging aren't really an issue at all.

Also all the development environments are running in Docker containers that the individual developer can restart to make a total reset if he/she desires to.

It would be greatly appreciated if we could configure VSCode to use a much longer timeout or to not kill the sessions at all.

[roblourens]

Actually closing this as a dupe of #440. Also #3096