I find that if I leave my VS Code Remote SSH connection open it disconnects automatically after a certain amount of time. Following automatic disconnection I find the Remote SSH then fails: when I try to log in again I get repeated requests for my remote password and every time I enter my password I just get another password prompt.
My current workaround is to go to the Command Palette and do "Remote-SSH: Kill VS Code Server on Host". Sometimes I need to do this multiple times for it to take effect. Then when I next log in there is a lengthy VS Code installation script that needs to run before I can start coding again.
Is there a way of setting up VS Code Remote SSH that avoids this issue? I have tried some of the suggestions on this page - https://code.visualstudio.com/docs/remote/troubleshooting. However I feel like I am completely in the dark regarding what the underlying issue is. I do not even know how I could go about generating informative diagnostics / a log.
Maybe the problem is that the remote machine has a limited number of proccess to run at same time. When a automatic disconnection of vscode happen, the that session is still running, but you cannot create a new one because you are over the limit in number of process.
In my case, asking to the remote machine to kill my process (manually done by the technician working in that machine in this case) works.
A better solution will be close the vscode sessions from your machine, to be able to start a new one again.
Related
When you're running VS Code Remote SSH and loose network connectivity over a long period of time and return to VS Code, the status on the bottom left show's "Disconnected from SSH: ". However, there doesn't seem to be a way to reconnect the session. I always have to revert to starting a new VS Code Remote SSH session. How can I reconnect?
You can reload the window. It keeps unsaved changes even.
Press F1 to search for commands, then search for:
Developer: Reload Window
Version of VSCode when trying this: 1.53.2.
EDIT: This does NOT work to reestablish the connection. It only helps to keep it alive. Thanks for the comments. I misinterpreted the question while looking for something similar for myself.
I'll leave the answer just in case it helps someone else.
You need to set a custom ssh file and add parameters to keep the connection to your host alive :
Host SomeRemoteHost
HostName MyRemoteHostName
User MyUsername
ServerAliveInterval 60
ServerAliveCountMax 30
Go to the SSH extension settings and set the new custom ssh config file path. This won't work if your machine goes into sleep mode, but it will keep the connection alive in the background while you work on other things.
PS: Make sure your ssh settings are correct for the host or you won't be able to log in.
It seems that there is something that drops your idle connection. As I know SSH doesn't have any configuration for dropping an idle connection but firewalls has. there might be some sort of firewall or monitoring software or hardware device which drops your connection. if you are using Linux OS the following command might help you:
ssh -o "ServerAliveInterval 60" <SERVER_ADDRESS>
this command sends keep alive request to ssh every 60 seconds.
In line with #PaulOmta answer, the easiest way is now adding this Reload button extension! It adds a Reload button to your status bar on the bottom right.
I found that ⌘-R shortcut didn't work on mine (maybe because I have other keybinders on)
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=natqe.reload
I'm currently trying to access a remote server using VS Code's Remote SSH extension. I haven't had a problem when using it before (that was around a month ago) but today when I tried to access the server I ran into some trouble.
I have the hostname and everything configured in a config file, and so I just click on that option and type in the password. However, VS Code seems to be stuck on "Opening Remote..." for the past hour or so. The dialogue I get in the terminal is as follows:
username#host's password:
Running remote connection script
Acquiring lock on /home/username/.vscode-server/bin/abcdefghijklmnop1234567989/
vscode-remote-lock.abcdefghijklmnop1234567989
Installing to /home/username/.vscode-server/bin/abcdefghijklmnop1234567989...
Downloading with wget
Does anybody know what the problem might be? Is this normal?
EDIT
As soon as I posted this the connection was successfully made. However, I would also like to still know what the problem was and if it normally takes around an hour, and what this process might be doing. I also believe it would be helpful to the community overall.
Thank you.
I've faced the same issue just now and realized that firewall protection has something to do with it.
As soon as I disabled it, the remote connection was established and I managed to see my code again.
I've got a batch file dmx2vlc which will play a random video file through VLC-Player when called.
It works well locally but I need this to happen on another machine on the network (will be adhoc) and the result (VLC-Player playing the video) must be visible on the remote screen.
I've tried SSH, Powershell and PsExec, but both seem to run the batch file and the player in the session of the command line, even when applying a patch to allow multiple logins.
So IF I get to run the batch file it is never visible on screen.
Using Teamviewer and the like is no option as I need to be able to call all this programmatically from my dmx program.
I'm not bound to being able to call the batch directly, it would be sufficient for me if I could somehow trigger it to run.
Sadly latency is a problem here as we are talking about a lighting (thus dmx) environment.
Any hints would be greatly appreciated!
You can use PSexec if the remote system is XP with the interactive parameter if you state the session to interact with, 0 would probably be the console (person physically in front of the machine).
This has issues with Windows Vista and newer as it pops up a prompt to ask the user to change their display mode first.
From memory, you could create a scheduled task on the remote system pretty easily though and as long as it's interactive the user should see it.
Good luck.
Try using web interface. It is rather easy: VLC is running http server, and accessing particular URL from remote machine will give full control over VLC. Documentation can be found here
I'm trying to access a remote davs server with emacs through tramp. I use the syntax
/davs:username#servername.fr: TAB
With ftp, this would ask for a password, connect to the server and open a completion list. But with davs Emacs gives the error Package tramp-gvfs' not supported`. Checking the messages buffer the error is linked to "completion--some" so I'm not sure it has to do with tramp itself. In the messages buffer I also see
Opening connection for davs using scpc... \
Tramp: Opening connection for davs using scpc...done
byte-code: Process died
I tried to specify the port number by adding #2078 after servername.fr but it didn't make any difference.
The connection works fine with my file managers (Nautilus and Thunar) so I suppose gvfs is set up properly on my system. Where else should I look?
You get this error message if Emacs is not compiled with DBus support, if it cannot connect to the session bus, or if neither gvfs-fuse-daemon nor gvfsd-fuse is running. (See the definition of tramp-gvfs-enabled.)
I seem to remember that I had to start gvfs-fuse-daemon manually, but I'm not sure exactly what I did to get it work; this was a long time ago on a different computer... Hopefully someone else can come up with a more complete answer.
I have a large repository of C++ code on a remote cluster (linux OS). When I need to work on this code from my home computer (Ubuntu OS), I try to access these codes through emacs on X windows. However the X window connection is very slow making the editing a painful process. So I sometimes move files manually between my local drive and remote cluster to edit the files. My question is: is there a way to configure my local emacs, such that when I edit the file in my local space, it would automatically be backed up in the cluster where it can then be compiled?
UPDATE:1
I installed TRAMP and it works well for servers that can be connected directly. However I also have servers which can be connected only when I activate VPN. How to provide the VPN information to TRAMP to connect to this server?
The other question I had was how to stop the TRAMP when it waits for prompts from remote shell without having to kill the whole emacs buffer.
This is typically a use case where TRAMP would be useful.
Instead of connecting to the server using SSH and opening Emacs there with X forwarding, run Emacs on your box and open your files remotely using TRAMP. For example:
C-xC-f/ssh:user#host:/remote/path/to/the/fileRET
This way, your Emacs process runs locally, but all file operations (e.g. save, revert, ...) are forwarded to the server, and all shell commands issued from TRAMP buffers also run on the remote server (this includes M-x compile)
UPDATE:1
When TRAMP hangs waiting for a remote shell prompt (which tends to happen frequently for reasons which are still obscure to me), I usually kill the underlying ssh process (htop with tree-like view is a good tool to do this) . TRAMP notices this and automatically respawns the killed process to resume operations.
Wouldn't it be easier to run Emacs in a console on the remote server? All Emacs functions can be access via the keyboard and once you get used to the key combinations it usually works out faster.
That way you will be running faster than forwarding an X session - running in a console is what Emacs was designed for.
As an added bonus - if you get used to using Gnu screen - http://www.gnu.org/software/screen/ you can pick up your sessions exactly as they were if the connection drops. In fact with screen you can shutdown your laptop at the end of the day - login over SSH the next day and pick up all your 'screens' exactly as they were the day before. This will include any open editors, debug sessions etc.
Gnu screen is available as a package on Debian and probably most Linux distributions.