vscode-remote-release
vscode-remote-release copied to clipboard
microsoft
Persistent SSH session
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:
- User connects to some remote server via the Remote SSH extension
- They do some work
- They get interrupted and close their local VS Code instance
- They do something else for a couple of days
- 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.
https://github.com/microsoft/vscode-remote-release/issues/1790 also related.
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)
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.
This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 10 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!
:slightly_smiling_face: This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!
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!
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!
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
Glad to hear that this feature request was received, it would be very useful for my working context.
Hopefully the timeout considers people coming back to work from long weekends, and resuming/waking up a sleeping computer/laptop :)
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?
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.
@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.
@lrnv It supports tmux now https://discourse.julialang.org/t/ann-vs-code-extension-1-2-released/62118
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 )
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!
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.
+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.
+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.
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
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.👍
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.
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?
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.
@roblourens is there an update on this feature? This would be a game-changer, please implement this!
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.
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.
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:
- is there a workaround or solution in place yet?
- 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?
- 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?
- 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?
- Are these features in work?
btw , why all the thumbs down on this post? L
