I've got my SSH keys in place, and can log into the server just fine from my terminal, but when trying to SSH via VSCode... I get the following errors over and over again:
ssh fork: retry: No child processes
I also noticed that when VSCode is connecting to my server... I can't connect via SSH in Terminal, and I have to manually halt the processes for VSCode on the server to be able to connect again.
Any ideas on this one?
The error is the result of the parent process waiting the child after a fork().
The error means that your running low on resources or you have created to many processes and the bash can no longer create any process.
Can you avoid automatically connection retries?
Related
I'm using VSCode 1.72.2 with Remote-SSH v0.90.1 on Windows to develop against an AWS EC2 VM running Ubuntu 22.04 LTS. A couple days ago, I was working in my project source folder in /opt/t4/ on the target host. When I was finished, I stopped the VM from the AWS console, forgetting that VS Code was still SSHed in.
When I brought the VM back up, I can reconnect VS Code/Remote-SSH to the host as before, except that I can no longer connect using /opt/t4/ as my working directory. I can use any directory except the one I was using when I disconnected.
I can navigate down to it and work in it if I use /opt/ as my working directory. I can navigate to it by manually SSHing to the remote host. I can create a subfolder in a remote shell at /opt/t4/test/, and then connect VS Code using that subfolder as my working directory. I can see and select /opt/t4/ in the Open Folder dialog in VS Code. But when I try to connect using that working directory, the connection times out with a not-particularly-useful error message:
[00:05:49.867] SSH Resolver called for "ssh-remote+my.remote.host", attempt 2, (Reconnection)
[00:05:49.868] SSH Resolver called for host: my.remote.host
[00:05:49.868] Setting up SSH remote "my.remote.host"
[00:05:49.870] Using commit id "d045a5eda657f4d7b676dedbfa7aab8207f8a075" and quality "stable" for server
[00:05:49.872] Install and start server if needed
[00:05:49.874] Using SSH config file "C:\Users\me\.ssh\config"
[00:05:49.874] Running script with connection command: ssh -T -D 1518 -F "C:\Users\me\.ssh\config" "my.remote.host" bash
[00:05:49.875] Terminal shell path: C:\WINDOWS\System32\cmd.exe
[00:06:06.876] Resolver error: Error: Connecting with SSH timed out
at g.Timeout (c:\Users\me\.vscode\extensions\ms-vscode-remote.remote-ssh-0.90.1\out\extension.js:1:585348)
at Timeout._onTimeout (c:\Users\me\.vscode\extensions\ms-vscode-remote.remote-ssh-0.90.1\out\extension.js:1:679743)
at listOnTimeout (node:internal/timers:559:17)
at process.processTimers (node:internal/timers:502:7)
[00:06:06.877] ------
I tried Remote-SSH: Uninstall VS Code Server from Host from VS Code.
I tried deleting ~/.vscode-server on the Linux host from an SSH session.
I tried Remote-SSH: Kill VS Code Server on Host from VS Code.
I tried Remote-SSH: Kill Local Connection Server for Host from VS Code.
I tried deleting and recreating the host connection details in the local config file from SSH-Remote.
I tried rebooting both local and target hosts.
I tried setting /opt/ as my working dir, then deleting and recreating /opt/t4. I was able to do this, but as soon as I try reconnecting using /opt/t4 as the working dir, VS Code still fails to connect.
I'm... stumped. My suspicion is that there is something corrupt cached Windows-side, but I don't know where to look for that.
Microsoft is aware and working on a fix. There are a variety of workarounds in this thread: https://github.com/microsoft/vscode-remote-release/issues/7324
Thanks to the link from #Mike Barry, I managed to find the local workspace for that target folder and delete it to force it to reinitialize, which cleared the issue.
Deleted C:\Users\me\AppData\Roaming\Code\User\workspaceStorage\[guid]\ and reconnected with no problem.
I'm using vscode with the remote ssh plugin, I can connect normally, but I need that right after synchronizing with the server, a linux command is executed when opening a connection, that is, this command has to be executed, in fact it is a sudo, I need that it is already synced as root, thanks
Beginning today, I am unable to connect to my remote server in VSCode. The error in the output shows this repeating 5 times:
[15:34:11.799] SSH Resolver called for "ssh-remote+my-server", attempt 5, (Reconnection)
[15:34:11.805] SSH Resolver called for host: my-server
[15:34:11.808] Setting up SSH remote "my-server"
[15:34:11.819] Using commit id "d045a5eda657f4d7b676dedbfa7aab8207f8a075" and quality "stable" for server
[15:34:11.832] Install and start server if needed
[15:34:11.849] Running script with connection command: ssh -T -D 53101 "myserver" bash
[15:34:11.857] Terminal shell path: C:\WINDOWS\System32\cmd.exe
[15:34:28.879] Resolver error: Error: Connecting with SSH timed out
at g.Timeout (c:\Users\username\.vscode\extensions\ms-vscode-remote.remote-ssh-0.90.1\out\extension.js:1:585348)
at Timeout._onTimeout (c:\Users\username\.vscode\extensions\ms-vscode-remote.remote-ssh-0.90.1\out\extension.js:1:679743)
at listOnTimeout (node:internal/timers:559:17)
at process.processTimers (node:internal/timers:502:7)
[15:34:28.948] ------
The port number in that SSH command is different for each attempt. If I copy that command out and run it in cmd manually from my local machine and add in -vvv, then I see the connection is successful and the prompt sits on "debug2: exec request accepted on channel 2" infinitely. I can't tell what the problem is. Is the local forwarding port failing to be created and listen on? Is there something with the remote server causing the timeout? Oddly, if I delete the .vscode-server directory on the remote and try to reconnect, then it actually does reinstall it fine. But I still get the error that VSCode can't connect to the remote server.
I forgot that the VSCode Remote extensions have their own repository. Turns out my issue is https://github.com/microsoft/vscode-remote-release/issues/7324
Ensuring that I set remote.SSH.useLocalServer to true in my user settings.json fixed the issue until it is resolved in-code.
I try to run the server for ssa by using ssaserver& command but I face this error on my server machine
from yesterday.
Error creating listening socket at [host name : port number] the network address may be in use.
I really don't know why it is showing this error and how can be the address in use.
My OS is RedHat7.
That is really happen because you maybe closed your terminal or logged out from current user account in RedHat.
To solve this issue you can use this command here:
ps -ef|grep ssaserver
Which will show you if the service ssaserver already in use and from this you can get the service id and child ids.
You can then kill the service id by using kill command:
kill #(serviceid)
Here is a link to show you how to use kill command: Link_1
But you can face this problem again and again so I think it will be fine if you will use nohup command to run the service you need.
Note: nohup is a command used to run a process(job) on a server and have it continue after you have logged out or otherwise lost connection to the server
Such as:
nohup ssaserver&
Here is extra link for nohup examples: Link_2
When veewee is displaying the following message, Waiting for ssh login on 127.0.0.1 with user veewee to sshd on port => 7222 to work, timeout=10000 sec what exactly is it waiting on?
As far as I can tell there is a ssh server on port 7222 on the host that veewee has put up and it's waiting on that. This means that something in the guest is going to connect back to it. However, I can't figure out what that thing might be - and thus I can't debug further.
Further details
I'm trying to build a virtualbox image for vagrant with the CentOS-6.3-x86_64-minimal template. My steps:
bundle exec veewee vbox define 'ejs-centos6.3-1' 'CentOS-6.3-x86_64-minimal'
wget http://mirror.symnds.com/distributions/CentOS-vault/6.3/isos/x86_64/CentOS-6.3-x86_64-minimal.iso
bundle exec veewee vbox build 'ejs-centos6.3-1'
The CentOS install appeared to run without error but it's stuck waiting for the ssh login.
You're right, there's a Ssh server on listening on port 7222, but it's on the guest (VM), not the host.
The host (Veewee) is waiting to connect to it. This SSH service is supposed to become available when the VM install process finishes, that's one of the steps used by Veewee to assume that the setup went fine and that the VM is ready.
If Veewee blocks and never gets this SSH connection, I think there could be multiple reasons:
VM setup went wrong and something prevents it from finishing successfully. Check Veewee output and the Virtualbox VM graphical console that should have opened when launching vewee box build.
There's something preventing your host computer to connect to the VM at the network level.
The VM image doesn't have Sshd installed, and/or the veewee box configuration files (in veewee/definitions/ejs-centos6.3-1/) miss instructions to install the ssh package
You should try to login to the VM using Virtuabox console window and check if there's an ssh package installed (rpm -qa | grep openssh-server) and a process named sshd running.
I've run Veewee against Centos 7 built with GUI on and it stuck on anaconda asking for source of packages. I've checked the ks.cfg and it was pointing to dead resource (404). After pointing to valid url it went through.