Persistent SSH session

[davidanthoff]

A lot of users of our Julia extension love the remote SSH features, they are super useful in a scientific research computing context!

One thing that has come up a lot lately, though, is that folks want an ability to have a persistent session on a server that they can disconnect from and then reconnect to way later.

The scenario is essentially something like this:

1. User connects to some remote server via the Remote SSH extension
2. They do some work
3. They get interrupted and close their local VS Code instance
4. They do something else for a couple of days
5. The now want to reconnect to the server, and ideally nothing was shut down on the server. For example, if they opened a REPL in step 2 and started a Julia instance in that REPL, it would still be running, and was never shut down. Similarly with pretty much all other runtime state they had.

I think this might be related to https://github.com/microsoft/vscode-remote-release/issues/440, but what I'm really asking for is not just an option to change the timeout, but some way to make the timeout infinit, so that the server session never shuts down.

This might also require some kind of UI, maybe a command like "Disconnect but keep server alive" or something like that, not sure.

[xgdgsc]

https://github.com/microsoft/vscode-remote-release/issues/1790 also related.

[EricChen1248]

Not a perfectly solution, but what about opening the terminal into Screen. Users could reconnected back to their screen session each time, also gives more fine grain control over resource releases (properly terminating a process vs an always persistent session)

[PavelSosin-320]

This is a well-known pattern in the Cloud Applications. The problem is always that lifecycles of Server and client are not synchronized and either server or client or connection can go down at any point all clients will hang. Then, clients have to re-authenticate. If the client is idle at the point of time was idle its user will have no knowledge of how to proceed. To avoid such a died-end situation client needs awareness of the "session status" i.e. Server needs session management and ability to report either current session status to the client, at least, by the explicit client's request or every re-connect request coming from the client has had session attribute. There is also a security risk that the session can be hijacked by anybody who has a valid login of the server when the client was idle.

[janosh]

Glad I found this! Just wanted to mention that I believe this is far larger in scope than the Julia extension. I bet most people forced to work from home these days would really appreciate this feature!

[bobaoapae]

This is what i need for stop using RDP to remote developmet. Sometimes i need keep service runing for several days and i don't want keep my own pc on just for it. Keep process running without vscode remain connected and re-establish connection/state after re-open vscode will be amazing!

[tom-programming]

This would be a real game changer for myself, and I believe, a whole lot of people. Now I use tmux to achieve the same but it is uncomfortable in many ways

[mineralres]

Glad to hear that this feature request was received, it would be very useful for my working context.

[ImMrMa]

Is there any progress on this feature recently?

[abhijithda]

Hopefully the timeout considers people coming back to work from long weekends, and resuming/waking up a sleeping computer/laptop :)

[taiya]

This would be a real game changer for myself, and I believe, a whole lot of people. Now I use tmux to achieve the same but it is uncomfortable in many ways

Agreed, e.g. tmux interferes with mouse scrolling, and does 100x other things on top of having just a persistent SSH session. Considering vscode has a server running remotely... it shouldn't be impossible to have a keep-server-alive mode?

[ImMrMa]

It has been nearly two years since this issue opened. Could we pay a little attention to solve the problem? I think it is a great improvement to users.

[lrnv]

@davidanthoff Is there some kind of workaround available for a remote and long-lasting Julia session, that would allow disconnecting and reconnecting multiple times without losing the (remote) Julia REPL ? In both cases, what is your current workflow for this kind of remote developpement ? It seems like the Julia extension has a 'remote development' section in its documentation, but sadly empty.

[xgdgsc]

@lrnv It supports tmux now https://discourse.julialang.org/t/ann-vs-code-extension-1-2-released/62118

[restyler]

I would be happy if VS code finally managed to restore all terminals properly after SSH disconnect. If other node.js developers sometimes launch nodemon process and then struggle to kill the detached nodemon session because of VS Code remote lost session, here is a set of commands how to quickly locate the nodemon PID & kill it: https://pixeljets.com/blog/killing-detached-nodemon-process/ (second part)

My major pain with tmux in VS Code Remote is that I can't copy&paste text to my vs code editor. Is there an easy way to fix it? I tried xclip on my remote Ubuntu and

set -g mouse on
bind-key -T copy-mode-vi MouseDragEnd1Pane send-keys -X copy-pipe-and-cancel "xclip -se c -i"
bind-key -T copy-mode MouseDragEnd1Pane send-keys -X copy-pipe-and-cancel "xclip -se c -i"

from https://www.vinnie.work/blog/2020-11-24-why-so-hard-tmux-copy-paste/ article without any success. Apparently it is not good for VS code terminal approach which is understandable - we have another link in our chain (Mac <-> Ubuntu <-> tmux )

[ImMrMa]

I would be happy if VS code finally managed to restore all terminals properly after SSH disconnect. If other node.js developers sometimes launch nodemon process and then struggle to kill the detached nodemon session because of VS Code remote lost session, here is a set of commands how to quickly locate the nodemon PID & kill it: https://pixeljets.com/blog/killing-detached-nodemon-process/ (second part)

My major pain with tmux in VS Code Remote is that I can't copy&paste text to my vs code editor. Is there an easy way to fix it?

agree with you! copy&paste text tmux info to my vs code editor is difficult!

[lucasresck]

Is there a workaround for persistent Jupyter Notebooks through SSH connection in VS Code? After reconnecting to remote, I would like to reconnect to my Jupyter kernel, or at least to keep the notebooks running.

[fpickard]

+1 for this feature request. It would be great to have native ssh session persistence as a first class feature, instead of DIY via screen/tmux as others have commented.

[march1993]

+1 for this feature request. I have to re-open several terminals and each different commands in each window, which is quite annoying everytime I launch vscode and open the project.

[nkutbw]

Is there a workaround for persistent Jupyter Notebooks through SSH connection? After reconnecting to remote, I would like to reconnect to my Jupyter kernel, or at least to keep the notebooks running.

You could combine nohup and port mapping. More detail could be seen here

[nkutbw]

Now I am considering using nohup and port mapping to open a code-server, which could be seen as a browser vscode. I prefer vscode to jupyter lab mainly for its vim extension. If the Persistent SSH session function is implemented locally, you will be the best ide in my heart.👍

[lucasresck]

You could combine nohup and port mapping. More detail could be seen here

Hi there, thanks for your answer. I think this applies to standard Jupyter Notebook and JupyterLab through CLI, right? I was thinking more about a way to have this working for notebooks inside VS Code too. I edited my comment to specify the question for VS Code.

[lucasresck]

Now I am considering using nohup and port mapping to open a code-server, which could be seen as a browser vscode.

In this case, the VS Code server would be opened in the remote machine and you would access this through standard SSH connection? Interesting idea.

Why using nohup instead of screen?

[nkutbw]

Now I am considering using nohup and port mapping to open a code-server, which could be seen as a browser vscode.

In this case, the VS Code server would be opened in the remote machine and you would access this through standard SSH connection? Interesting idea.

Why using nohup instead of screen?

Yes, you are right. And as a non root user, it is more convenient for me to use nohup. Anyway, we all look forward to a Persistent SSH session in vscode internally just like a terminal or notebook opened in a "nohup" jupyter.

[mcpeixoto]

@roblourens is there an update on this feature? This would be a game-changer, please implement this!

[LeanderK]

I would also really like to see this! I always work remote and the loss of the session when my computer goes into sleep just drives me mad.

[mschrader15]

Plz implement! This will be awesome

[janosh]

Let's all avoid the repeated requests to implement this else they'll probably lock the issue. Just upvote to give it higher prio in triage.

[shengbeiniao]

Mark

[lifeatthesharpend]

I know I'm coming in late to this thread, but here goes. I'm probably a newb so please be patient. This seems to be related to a few other closed issues mainly:

• Retain remote session when coming back to VSCode from computer sleep #3355
• Allow session detach & re-attach over long periods of time #1701
• Custom reconnect timeout #1185
• Long running kernels #3998 few others that have closed as well.

My questions are:

1. is there a workaround or solution in place yet?
2. from what I can tell some are using tmux. I know how to use tmux from the terminal but not exactly sure how to best set it up using VS-code. Is there a step-by-step instructions for how to use tmux with vs-code?
3. I believe that @roblourens mentioned a 3 hours reconnect. Is there a setting for this can this be extended to longer, for example 24 hours?
4. Is there a way to put the vs-code session in background mode then comeback to it? For example start a python debug run, detach, then travel with the computer, then the next day open , restart computer then re-attach? All this without forcefully disconnection?
5. Are these features in work?

btw , why all the thumbs down on this post? L

[coconutattitude]

How it's going with this 2.5 year-old issue?

[chang803]

It would be really useful if we could have this configurable timeout reconnect feature. I believe right now it's 8 hours, which is already increased from 3 hours But I launch long simulation(>10 hours) through vscode-remote before I go to sleep, when I come back they are killed. I understand tmux can help with the issue but I have to talk to IT and a lot of other folks to get it installed on the remote machine.

I would really appreciate the configurable reconnect time feature. Thanks!

[xgdgsc]

Yes. I don' t understand how is it so hard to change a single integer before a setting is added. Please change to 168.

[chang803]

Any update please?

[shittiidavincii]

+1 for an update, persistent ssh using screen or the like would be great.

[Boris94cr]

Any update on this feature?

[ferreirafabio]

Any update on this feature? Thumb me down as much as you want but we need this feature.

[holland11]

+1. Currently using screen to achieve something similar, but there are a lot of hoops to jump through to get it working. And the most recent vscode update seems to have broken my screen process (now, whenever the vscode session times out while I am attached to a screen session in the vscode terminal, the screen session becomes unresponsive when I try to reconnect to it and eventually it says it's dead; it used to just let me reconnect to it without issue; going to downgrade my vscode to hopefully get it working again).

For anyone looking to try using screen within the remote vscode terminal, one thing you should be aware of is that to get the code <file> functionality to work (so that you can use the code command in the vscode terminal to open remote files), vscode sets up some EVs in its native terminal session.

VSCODE_GIT_IPC_HANDLE
VSCODE_IPC_HOOK_CLI

When you first create a screen session through the vscode remote terminal, it will inherit those EVs and so you will still be able to use code to open files. However, once the vscode session times out and you reconnect to it, this will generate new EVs and invalidate the old ones. Then you reconnect to the old screen session with its outdated vscode EVs and code <file> will throw an error. To fix this, you need to refresh the screen session's EVs (specifically the ones I mentioned above).

I have this happen automatically with a pair of shell functions (zsh, but might work with bash as well).

update_screen_evs() {
  if [[ -f ~/screen_logs/temp_ipc_handle ]] && [[ -f ~/screen_logs/temp_ipc_hook ]]; then
    value=$(<~/screen_logs/temp_ipc_handle)
    export VSCODE_GIT_IPC_HANDLE="$value"
    value=$(<~/screen_logs/temp_ipc_hook)
    export VSCODE_IPC_HOOK_CLI="$value"
    echo "EVs imported."
    return
  fi
  echo "EV files not found."
}

scrn() {
  if [[ $# != 1 ]]; then
    echo "Must provide screen name."
    command screen -ls
    if [[ $STY ]]; then
      echo "Current screen session: $STY"
    fi
    return
  fi
  command echo "$VSCODE_GIT_IPC_HANDLE" > ~/screen_logs/temp_ipc_handle
  command echo "$VSCODE_IPC_HOOK_CLI" > ~/screen_logs/temp_ipc_hook
  command screen -S $1 -X stuff 'update_screen_evs
  '
  command screen -RDS $1
}

Using scrn <session_name> will reconnect to an existing session named <session_name> if it exists (or will create it if it doesn't). Before doing that though, it will copy the native terminal's vscode EVs to files located in the ~/screen_logs/ directory (so you'll probably need to manually create this directory first) and send the update_screen_evs command to that session (if the session exists).

(The update_screen_evs command is sent as raw text with an explicit RETURN character. So if that screen session already had text in its user input buffer, the text will have update_screen_evs concatenated with it before being returned. Which will likely fail. So in these cases, you'll have to manually run update_screen_evs upon reconnecting to the session.)

Would be great if vscode could just get persistent terminal sessions natively supported.

[apizz]

How can we get this moved from the backlog into development?

[x66ccff]

Any update on this feature?

[kingpalethe]

This is the single feature as far as I can tell where cloud IDE solutions like cloud9 have some significant advantage over VSCode. Would love to figure out how to do this with VScode instead.

[Kaiserouo]

Uh so as far as I can tell there is no VSCode solution for this yet? I guess screen or tmux could work but if this can work under all those terminal tabs it would be perfect...

[TatIwamoto]

Shouldn't require tmux or screen to get the sessions persistent across disconnects.

[aminfardi-CD]

+1 for wanting a native solution on this. Can't get tmux to work for Jupyter notebooks in remote sessions.

[ymerouani]

I just went through the trouble of setting everything up just to find out at the last step that there is no way to let my jupyter notebook run remotely when I close my local machine. I don't know if I should cry or laugh. Please give us this possibility

[ltalirz]

This is by far the top-voted issue on vscode-remote-release now

Message from user community seems clear

[aiojfunbf]

Hi, is there any solution for it now?

[aminfardi-CD]

@matriim @aiojfunbf I found feature request 13276 in development which seems to be slated for May 2023 release. Hoping it's what solves all our problems.

[cqlc94]

Any update now? Would be extremely useful

[AgFlore]

One workround for now (only for users who wants the remote-server persistent FOREVER, not for users who wish to change the timeout value):

vscode starts the remote server by launching sh <vscode-server-bin-path>/bin/code-server --start-server --host=127.0.0.1 --accept-server-license-terms --enable-remote-auto-shutdown --port=0 --telemetry-level all --connection-token-file <path-to-token-file> in your default shell (/bin/bash in my case) after it established the SSH connection.

Therefore, just remove the --enable-remote-auto-shutdown argument, and the server will run without the idle timeout. This can be achieved by a customised wrapper for sh. My version goes like:

#! /bin/bash

args="$@"

ignore_me='--enable-remote-auto-shutdown'

if echo "$@" | grep -q -- "/.vscode-server"; then
    if echo "$@" | grep -q -- "$ignore_me"; then
        args=$(echo "$@" | sed "s/$ignore_me//g")
    fi
fi

/usr/bin/sh $args

And then export PATH=<path-where-you-put-that-wrapper>:$PATH in .bashrc (or into vscode's ssh-config, if you dislike polluting your shell environment). Now vscode will launch the remote-server without enabling the annoying idle-shutdown.

[Phil-Garmann]

@AgFlore can you verify that this workaround works? At least from my testing, it does not seem to remove the necessary argument. One comment: ./vscode-server should probably be /.vscode-server