Failed to connect to the remote extension host server due to unsupported, out of date libraries like glibc (e.g. older CentOS version) #103
Comments
|
@alexandrudima @wqfan You could try reinstalling by deleting the folder |
|
@roblourens Thanks for your follow up on this issue. I have tried deleting that folder a few times and it doesn't make any difference. |
|
Hi, Identical problem. But the same error This doesn't have sense! |
|
Debug info: This is my I hope it can be fixed soon. 😢 |
|
The same problem. > cat: ~/.vscode-remote/.473af338e1bd9ad4d9853933da1cd9d5d9e07dc9.log: No such file or directory
> Server did not start successfully. Full server log:
> cat: ~/.vscode-remote/.473af338e1bd9ad4d9853933da1cd9d5d9e07dc9.log411693af-6a8f-4de5-9053-7abf6ae26efe====
> : No such file or directory
"install" terminal command done
Received install output: : No such file or directory
Failed to parse remote port from server output: : No such file or directoryWhen I manually create the log file, connect the prompt again: > Server did not start successfully. Full server log:
>
> 127e184a-8aae-450a-9261-613691a553db====
"install" terminal command done
Received install output: 127e184a-8aae-450a-9261-613691a553db====
Failed to parse remote port from server output: 127e184a-8aae-450a-9261-613691a553db==== |
|
@kieferrm It can be a problem of the OS. Does the remote extension only work with Ubuntu? Unfortunately, this is the only development server I have and I can't change the OS. My |
|
@u3u I think you shouldn't remove the folder directly. Try the |
|
@wqfan I am not sure it's the OS. I just tried a public AL2012 EC2 instance (not AL2) and it worked just fine. (Of course it's named 2018.03 but we all know it's AL2012.) So the first thing I checked is sshd version. Are we screwed because our super-legacy dev desktops still use OpenSSL 1.0.1 for sshd? |
|
@khuongduybui Thanks for your information. I have upgraded OpenSSL and been using OpenSSH: The problem still exists. |
|
Same |
|
Would you know what we need to do to make |
Sorry! I don't want to offend anyone. My objective is provide feedback and ideas. 😉 |
The For what it's worth I'm seeing the exact same issue as op (not surprising given our mutual employer). |
|
Can I download |
Hi @iamatypeofwalrus , Three comments:
Regards. |
|
Just for another data point, I encounter the same backtrace attempting to connect to a remote server running RHEL6: $ grep -i error ~/.vscode-remote/.473af338e1bd9ad4d9853933da1cd9d5d9e07dc9.log
Error: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.18' not found (required by ~/.vscode-remote/bin/473af338e1bd9ad4d9853933da1cd9d5d9e07dc9/node_modules/spdlog/build/Release/spdlog.node)
$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.10 (Santiago)The same issue presumably occurs with CentOS 6.10: https://github.com/microsoft/vscode/issues/73427. |
Unfortunately I can't find the image to download anymore. |
Just download a newer version of |
|
Getting the same issue with RHEL6 [ac043s@SDNAUTOS02 .vscode-remote]$ uname -a [ac043s@SDNAUTOS02 .vscode-remote]$ grep -i error ~/.vscode-remote/.daf71423252a707b8e396e8afa8102b717f8213b.log Remote configuration data at /home/ac043s/.vscode-remote
Error: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.18' not found (required by /home/ac043s/.vscode-remote/bin/daf71423252a707b8e396e8afa8102b717f8213b/node_modules/spdlog/build/Release/spdlog.node) |
|
Did you modify anything to get this additional information in the log? I get this exact behavior but my log only contains (below the IP and visual studio code server banner): Extension host agent listening on 45799 and I get a new "Unauthorized client refused." entry every time I attempt to establish a connection. I would like to enable additional diagnostics but have not found anything to help. (already enabled the remote.SSH.showLoginTerminal: true) |
Hi @achhabr1 , |
|
Hi, Regarding this bug I discovered:
-- Note the "Platform" value of
-- And note here the error about the detection of the tty. So, here my conclusion:
I feel a lot of errors are caused because this bug. |
|
Another case where this error comes up, rather regularly, after updates for VSCode are installed. It seems to happen when having >1 remote sessions going on, possibly simultaneously. For example, I remote SSH to SERVER from PC1 and PC2, where PC2 uses a forwarded port on PC1, to avoid having to join a specific internal network. Maybe at some point VSCode gets confused and mislabels which session comes from where, but so far only PC1 goes into a state in which it is unable to get in. This seems to happen ONLY after PC2 upgrades VSCode locally, and presumably, the version server. It seems that the server process for PC1 does not get properly restarted/killed when another remote SSH client updates the VSCode server, and so when trying to connect at a later point it is still running an earlier version of the VSCode server. SSHing into SERVER and killing all live It seems my case is rather rare, and possibly not relevant to the original reported issue. It doesn't help that "Unauthorized client refused" is way too generic and gets misreported in this issue (myself likely included) because there's 50 different ways of getting the error. Perhaps it's worth changing the title to "Unauthorized client refused due to mismatching library versions / unsupported distro", as that seems to be the cause of OP's issue. |
|
This is happening to me daily now on different computers. Opening a VSCode instance on a remote server works fine, but opening up a workspace on a remote machine breaks. It's happened too and from both Ubuntu 18.04 and Centos 7. Restarting worked on Ubuntu, Centos 7 still isn't working killing all vscode instances or restarting. |
Chuxel
changed the title
|
@iiwolf I'd suggest opening up a different issue on that. This issue is about out of date OS dependencies that VS Code cannot support because of a fundamental dependency Node (often really V8) brings. I updated the title to make that clear. The feature request is to either use all statically compiled libraries (which increases download sizes and thus we do not want to do) or allow alternate path for the libraries. Any support we would be able to add here would be unofficial given our dependencies could break in other ways. It's also worth noting that Remote - SSH does not support |
Chuxel
changed the title
Chuxel
changed the title
|
Hi @Chuxel ,
Thank you for the response. However, please can you explain why allowing alternative path for the libraries could break something? As I pointed before (years ago), the ONLY problem to run the remote extension in old servers is that the current implementation of the agent wants to use a recent version of Node and some system libraries. But this is only necessary to run the agent. So, installing the required Node version with the necessary libraries it could work. Where is then the problem with this simple solution? Regards. |
Is it? I am (still) seeing the issue between two glibc Void systems, it's a rolling system and the packages are up-to-date. If you can point me toward figuring what the actual failing part is, or what is the unfulfilled dependency it would be very helpful. |
|
Hi @anddam ,
Sorry if this sounds quite rude... but don't waste your time! The developers of the vscode-remote extension doesn't want to support any environment. I feel they want to enforce to use only recent versions of Linux. The agent doesn't run in some systems only because it wants to use an specific version of the Node and it requires to be the regular node and linked to system libraries. As discussed some time ago, it is possible to hack the agent to run within an alternative environment. I hope at some time the developers will add the option to use and specific path for the Node runtime (like Regards. |
|
@anddam The minimum requirements are explained here: https://code.visualstudio.com/docs/remote/linux We have a set of Linux distributions we focus on listed in the document. Mileage may vary outside of it given the sheer variability on what each Linux distribution can contain. Beyond node, node modules can include native code, so its possible something else could be going on. To be clear, this error can also happen if you are not using an official VS Code release. We sometimes see packages marked as VS Code that are actually Code - OSS or something else, rather than an official distribution. This could also be causing a problem and isn't related to OS requirements. We left this issue open so people could compare notes rather than just locking the conversation. We're always appreciative of tips and would be happy to accept PRs to the vscode-docs repo with workarounds folks have found that work for distributions that the team is not directly focusing on at the moment. There's a "tips by distribution" section we setup with exactly this in mind. |
|
Hi, |
|
Hi @anddam ,
I really appreciate your comment. And please believe me when I say that I want to be positive. My aim is to present my point of view with due respect to all the developers of this great tool. That said, I suggest you to do this simple test:
The real test is this:
If the answer is yes, then why not support this? Regads. |
|
I found a solution to jump over this problem, which is to build |
|
Hi @youralmight ,
This an interesting workaround. But it's based on changing the VS Code with the code-server. Then it's not possible to use the Remote Extension (see: https://github.com/cdr/code-server/blob/v3.5.0/doc/FAQ.md#differences-compared-to-vs-code). In fact, what we want is to develop (compile/debug) in some target Linux environments that are not supported because they're consired old by Microsoft (even they could be compatible). Perhaps at some time a new opensource alternative of the plugin will appear: coder/code-server#1315. Regards. |
|
I'm having |
|
@Chuxel thank you so much for your work, Would you/the devs be willing to discuss adopting the solution in #103 (comment)? That implementation, of using the local node if it matches the required version, and defaulting to the current behavior of downloading if it does not, would solve 99% of the issues in this thread, dramatically improve using the number of distributions supported, all while minimally impacting support surface. The challenge with the solution is most people on this thread have not adopted it, as it requires patching this extension after every update. This isn’t hard to do as the source code is “just javascript.” |
|
VSCode (Insiders) runs on older distros (again?) as of Aug. 9 2021, because they could afford to statically link libstdc++:
I encountered this VSCode Remote - SSH "GLIBCXX_3.4.20' not found (required by [...]/node_modules/spdlog" issue on Oracle-Linux-7.9-aarch64 (ARM on the Oracle Cloud free tier). The solution is to put a newer version of libstdc++ earlier on the share library / dynamic loader path. I found the package to install by choosing the most recent version returned by Others have obtained libstdc++.so.6 for CentOS7 arch x86_64 by grabbing it from anaconda3, using Ghettoforge, or building from source. As far as I can tell, node-spdlog instantiates the header-only spdlog, which is tested all the way back to GCC 4.8.1. It might be worth changing the node-spdlog build to specify an old compiler version for maximum compatibility, e.g. GCC 4.8.3 / GLIBCXX_3.4.19 (I'm not sure that's right). |
|
Thanks for the workaround @jspraul. I was facing the same issue on Oracle Cloud "Oracle Linux Server 7.9" ARM machine. |
|
For NixOs added this to my configuration, providing a script that links to a working local node version. |
|
+1, I'm having this issue when using VSCode to connect to a running pod in a Kubernetes cluster. This is the output of executing 1.66.0 |
|
+1, Same here. |
|
+1, my colleague who are using vscode with this extension sent report and he cannot connect to a running pod in a Kubernetes cluster from 3days before.
Are there any way to avoid this? |
|
@quanvuong @gatheluck Downgrading the Remote - Containers Extension to v0.224.3 solved the issue for me. |
@daniel-scheliga @lnicola |
and others
Steps to Reproduce:
Failed to connect to the remote extension host server (Error: Connection error: Unauthorized client refused.)AllowTcpForwardingis enabled on the remote server.Here is the full output from "Remote - SSH" channel:
Logs from "Log (Window)" channel:
Does this issue occur when you try this locally?: Yes
Does this issue occur when you try this locally and all extensions are disabled?: Yes
The text was updated successfully, but these errors were encountered: