-
Notifications
You must be signed in to change notification settings - Fork 293
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Remote-SSH Bug]: 2nd connection always fails - Failed to parse remote port from server output #10445
Comments
It's this - |
I expect this is something particular about our local environment. A clue about what might be going wrong would be a great help. |
Yea, correct on the the issue here. From the log I can see the installation script is failing to open and read the log file, which will contain the port that needs get parsed out:
Looks like your $HOME directory is One thing you can try is experimenting with a different server install directory by modifying this setting (especially if this home directory is indeed not local to the remote machine). |
Hi @joshspicer thanks for the reply Indeed $HOME ( /afs/exampe.ch/user/s/me ) is a shared filesystem (AFS) Using a Server Install path of /tmp/ is definitely helpful and I do recommend it to my users. Is a shared file system known to intrinsically problematic? - It's hard directing users of the service away from defaults and My experience is that I observe the error message above even when the re-connection is to the same host so while shared it Is there a flock on .vscode-server/.cli.65edc4939843c90c34d61f4ce11704f09d3e5cb6.log ? #540 was fixed once but maybe its back. |
In fact what I see is a lot:
Those weird |
Yea, we've seen a lot of issue reports in the past around remote shares and the issues they cause (searching in this repo will find a fair few). Open to ideas, but I don't think there's too much we can do on our end if creating files is non-deterministic/error-prone on a given share. Specifically for your case, do you mean that other users could potentially overwrite these state files concurrently? In that case, i'd definitely recommend manually setting (or updating Lastly, there are some other "remote fileshare"-related settings you can see if help your specific use case, like |
Finding it hard to find the code that creates/deletes/parses this file. I totally get we are not using a real POSIX filesystem here, I am just trying to get to bottom of what is our problem. The code that creates and deletes this file is in |
The source code for the "CLI" in this sense can be found in the VS Code repo: https://github.com/microsoft/vscode/tree/main/cli. You've already found the process and arguments that are spawned on your remote machine to fascilitate the connection. This is an example line of what is happening on the remote host (checked in between the LISTENING_ON=$(cat "$CLI_LOG_FILE" | grep -a -E 'Listening on .+' | grep -v grep | sed 's/Listening on //') Could it be that the server correctly listening, but due to the underlying filesystem the log file is written lazily and a In case it looks different on your machine, this is the log file on my machine: |
Hi #10395 is indeed exactly the same - that looks to be a user of my service.
So yes its definitely in this area. The CLI_LOG_FILE is being written to and parsed potentially on different machines and the sync may not occur till the file is closed and On shutdown the file is emptied, is that expected?
|
An extra piece of information: Downgrading the remote SSH plugin to v0.106.4 things are better behaved for us.
I expect the .log file was not being parsed for the port back in this era. |
Using the latest updates for VSCode (1.95.3) and "Remote - SSH" extension (0.115.1) I still cannot connect from a Ubuntu 22.04 host to another Ubuntu 22.04 host. What does work is downgrading the "Remote - SSH" extension to 0.106.4, as recommended here. |
Is there an existing issue for this bug?
Required Troubleshooting Steps
remote.SSH.useLocalServer
setting (more info here)Connect Locally
It connects successfully
->
Connecting vscode to our servers works reliably.
However after exiting vscode and confirming the remote vscode has stopped on re-connection.
The second connection remote end starts up okay
is the correct port and the server is listening on that.
The situation can be fixed with a "rm -rf ~/.vscode-server" on the server side and again you can connect once but never a second time.
Only setting I have is keep lockfiles in /tmp though similar behaviour is seen with out that setting.
Expected Behavior
The on disk remote server should be started and connected to.
Steps To Reproduce
It fails as above.
Remote-SSH Log
Remote-SSH Log
Anything else?
Definitely worth mentioning that this with kerberos login and ~/.vscode-server on AFS file system.
What output we are failing to parse ?
The text was updated successfully, but these errors were encountered: