vscode: vscode server won't start: "Waiting for server log..."

Does this issue occur when all extensions are disabled?: Yes/No

  • VS Code Version: 1.86.0
  • OS Version: Windows 10.0.19044

Steps to Reproduce:

  1. Start vscode
  2. Observe log of remote SSH

I just restarted vscode after notification of a new version availability. This usually installs a remote server version. But this time, the server installation fails. Here is the log output of remote SSH:


[13:30:17.671] Using SSH config file "C:\Users\reiss\.ssh\config"
[13:30:17.672] Copying file to remote with "C:\Program Files\Git\usr\bin\scp.exe" -F "C:\Users\reiss\.ssh\config" "vscode-cli-05047486b6df5eb8d44b2ecd70ea3bdf775fd937.tar.gz" "vscode-cli-05047486b6df5eb8d44b2ecd70ea3bdf775fd937.tar.gz.done" "cplane_docker":"/var/fpwork/reiss/vscdata/server/cplane/.vscode-server"
[13:30:17.672] Using cwd: file:///c%3A/Users/reiss/AppData/Local/Temp/vscode_server_1706790617477
[13:30:17.672] Terminal shell path: C:\WINDOWS\System32\cmd.exe
[13:30:18.167] > vscode-cli-05047486b6df5eb8d44b2ecd70ea3bdf77   0%    0     0.0KB/s   --:-- ETA]0;C:\WINDOWS\System32\cmd.exe
[13:30:18.914] > vscode-cli-05047486b6df5eb8d44b2ecd70ea3bdf77 100% 8379KB  11.0MB/s   00:00    
[13:30:18.937] > 
> vscode-cli-05047486b6df5eb8d44b2ecd70ea3bdf77 100%    9     8.5KB/s   00:00    
[13:30:20.223] "Copy server to host" terminal command done
[13:30:20.295] > Found flag and server on host
[13:30:20.298] > af274c7fbd66%%2%%
> tar --version:
[13:30:20.299] > tar (GNU tar) 1.34
> Copyright (C) 2021 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> 
> Written by John Gilmore and Jay Fenlason.
[13:30:20.720] > code 1.86.0 (commit 05047486b6df5eb8d44b2ecd70ea3bdf775fd937)
[13:30:20.724] > Running ssh connection command... /var/fpwork/reiss/vscdata/server/cplane/.vscode-server/code-05047486b6df5eb8d44b2ecd70ea3bdf775fd937 command-shell --cli-data-dir /var/fpwork/reiss/vscdata/server/cplane/.vscode-server/cli --on-port --require-token a53956730956 --parent-process-id 52357 &> "/var/fpwork/reiss/vscdata/server/cplane/.vscode-server/.cli.05047486b6df5eb8d44b2ecd70ea3bdf775fd937.log" < /dev/null
> printenv:
....

[13:30:20.743] > Spawned remote CLI: 52461
[13:30:20.753] > Waiting for server log...
[13:30:20.803] > Waiting for server log...
[13:30:20.845] > Waiting for server log...
[13:30:20.884] > Waiting for server log...
[13:30:20.924] > Waiting for server log...
[13:30:20.963] > Waiting for server log...
....

[13:30:34.931] > Waiting for server log...
[13:30:34.968] > Waiting for server log...
[13:30:35.010] > Waiting for server log...
[13:30:35.050] > Waiting for server log...
[13:30:35.085] > af274c7fbd66: start
> SSH_AUTH_SOCK====
> DISPLAY====
> listeningOn====
> osReleaseId==rhel==
> arch==x86_64==
> vscodeArch==x64==
> bitness==64==
> tmpDir==/tmp==
> platform==linux==
> unpackResult==success==
> didLocalDownload==1==
> downloadTime====
> installTime==404==
> serverStartTime==14348==
> execServerToken==a53956730956==
> af274c7fbd66: end
[13:30:35.085] Received install output: 
SSH_AUTH_SOCK====
DISPLAY====
listeningOn====
osReleaseId==rhel==
arch==x86_64==
vscodeArch==x64==
bitness==64==
tmpDir==/tmp==
platform==linux==
unpackResult==success==
didLocalDownload==1==
downloadTime====
installTime==404==
serverStartTime==14348==
execServerToken==a53956730956==

[13:30:35.086] Failed to parse remote port from server output
[13:30:35.086] Terminating local server
[13:30:35.087] Exec server for ssh-remote+cplane_docker failed: Error
[13:30:35.088] Error opening exec server for ssh-remote+cplane_docker: Error
[13:30:35.096] Local server exit: null

There are hundreds of Waiting for server log... traces, so it seems like the server is not answering in time. The vscode startup fails with

image

I never had problems with updating vscode. Anyone else has this issue?

EDIT: I already tried to completely remove the old server installation. It makes no difference. It downloads the latest server and fails with same error.

About this issue

  • Original URL
  • State: closed
  • Created 5 months ago
  • Reactions: 109
  • Comments: 100 (7 by maintainers)

Commits related to this issue

Most upvoted comments

same here

As a side node: an update like this, which is “major” IMHO, should have a security mechanism involved. It could have checked the libc versions and refused the update. Now, many people are screwed in the middle of their work. A lot of room for improvement here…

Welp, just gonna add my name to the list. Can’t remote into many of my work servers now, and the page linked above is down, so I guess it’s back to vim for awhile.

A change this breaking really should’ve been a major version iteration with a confirmation required before upgrading, in my opinion.

I think so many others still use old distros. And they may be physically unable to upgrade GLIBC >= v2.28 due to their provider’s limitations. So, a version of statically linked binaries that runs on 2.28 or lower would be nice.

Yeah this has completely screwed me. I have a number of older servers and I can’t get into any of them now. The only way is for me to downgrade and never update VS Code. Doesn’t seem like a good solution.

@deepak1556 are there any steps to revert back to previous version of remote ssh? I am unable to use any of my machines and there is no plan soon to move to higher versions required by vscode.

  1. Downgrade local VS Code to 1.85.2
  2. Disable updates
  3. ssh into the remote server and delete ~/.vscode-server
  4. Remote into server from VS Code as usual

I don’t understand, why this update so aggresive, totally break up my working pipeline.

image image Seriously?

Breaking an entire workflow on an os that’s still supported with security updates for the next 4 years was definitely a choice

Edit: to downgrade with apt, you can run sudo apt-get install code=1.85.2*
Edit2: and then hold the version with sudo apt-mark hold code

Looks like old distros are no longer supported. I have the same issue on Centos 7.

The log shows:

error This machine does not meet Visual Studio Code Server's prerequisites, expected either...:
  - find GLIBC >= v2.28.0 (but found v2.17.0 instead) for GNU environments
  - find /lib/ld-musl-x86_64.so.1, which is required to run the Visual Studio Code Server in musl environments

As a mitigation step, please go ahead and disable updates after installing 1.85.2:

Also, please provide as many details as possible, especially error messages or notifications or terminal output.

This update is tooooo stupid.

Is there a better explanation for this decision? This completely screwed me over today. Seriously thought I was crazy.

@valium123 It’s the vscode you need to downgrade, not the plugin. And disable automatic updates, the download for the old version is provided here https://github.com/microsoft/vscode/issues/203967#issuecomment-1921540242

I also encountered the same problem, and it has now been resolved. Here is my solution for your reference:

  1. Install version 1.85.2 of vscode.
  2. Disable updates.
  3. Downgrade the remote-ssh version to 0.107. Now it works normally.

how to downgrad in macos ? i got two versions installed instead and i have to install the extensions again (apparently it’s not downgrade)

btw, i (perhaps many of us) cannot just simply ask our server admins to upgrade their related libs. so i urge that the vsc development team to consider a workaround.

  1. Get the 1.85.2 version of Visual Studio Code from this link: https://update.code.visualstudio.com/1.85.2/darwin-arm64/stable
  2. Unzip the .zip file and drag the application to the “Applications” folder to replace the existing version
  3. In the settings, search for “update” and change the mode from “default” to “none” to disable auto-upgrades. Then, install the “Remote-SSH” plugin and restart the application. If the restart has already updated to version 1.86, please repeat step 2. As the settings will not be auto-updated.

Is there a better explanation for this decision? This completely screwed me over today.

and even no warning before upgrade

What a smart ass to make a decision like that!

workaround solution to bypass glibc version check:

  1. remove ~/.vscode-server/* and ssh to remote again (would fail again, but can help reinstall node env)

  2. patchelf to change dynamic loader and reassign rpath; patchelf --set-interpreter ***/glibc-2.31/lib/ld-linux-x86-64.so.2 --set-rpath ***/glibc-2.31/lib:***/gcc-9.3.0/lib64 --force-rpath ~/.vscode-server/bin/<remote-id>/node

  3. skip prerequirement check; modify ~/.vscode-server/bin/<remote-id>/bin/helpers/check-requirements.sh Add exit 0 at the beginning of this file.

Thanks @yakouyang @PappeSister , I tried these steps:

  1. Install 1.85.2 version VS Code and overwrite the newest version 1.86.0
  2. Unset the auto-update mode image

This update makes me so annoyed…

i’ve got ubuntu 18.04

Apparently it is documented in the release notes: https://code.visualstudio.com/updates/v1_86#_linux-minimum-requirements-update

In this milestone, we have updated the toolchains to build our desktop client. From this release onwards, VS Code desktop is only compatible with Linux distributions based on glibc 2.28 or later, and glibcxx 3.4.25 or later, such as Debian 10, RHEL 8, or Ubuntu 20.04. If you are unable to upgrade your Linux distribution, the recommended alternative is to use our web client. If you would like to use the desktop version, then you can download the VS Code release 1.85. Depending on your platform, make sure to disable updates to stay on that version. A good recommendation is to set up the installation with Portable Mode.

But it looks like it refers to desktop, not remote development. @deepak1556?

Ubuntu 18.04 has glibc 2.27.

Having the same issue on Ubuntu 18.04. The only solution I found is not to updgrade, or if you upgraded just go back to an older version.

EDIT: thanks @deepak1556 for the information and the updated documentation

This is a really awesome update!!

I have the same issue but on AARCH64 with Debian 11. My glibc is 2.36 which is new. The log file on remote machine is completely empty. I only get “Waiting for server log…” on the desktop.

same to me I download a protable version of 1.85,and it will not conflict with 1.86 or future version. download

switching to the pre-release version of the remote-ssh extension gives me this popup before failing image I’m using Ubuntu 18.04 EDIT: I’m able to bypass the issue by downgrading to 1.85.2

The test-script bin/helpers/check-requirements.sh has a problem with more than one libstdc++.so.6 installed on the system.

In libstdcpp_paths=$(/sbin/ldconfig -p | grep 'libstdc++.so.6') all paths are gathered (in my case two versions with two architectures). With libstdcpp_path=$(echo "$libstdcpp_paths" | grep "$LDCONFIG_ARCH" | awk '{print $NF}') the results are reduced to matching architecture, but there can still be more than one.

Finally in libstdcpp_real_path=$(readlink -f "$libstdcpp_path") calling readlink does not find the file with two names.

Might be only checking one version with: libstdcpp_path=$(echo "$libstdcpp_paths" | grep "$LDCONFIG_ARCH" | awk '{print $NF}' | sort -r | head -n 1) might make sense?

Same issue, I failed to log in to the remote server, does anyone have any method to fix it?

try to create on remote /tmp/vscode-skip-server-requirements-check empty file (touch /tmp/vscode-skip-server-requirements-check) then try to attach

Thanks a lot, does it work on the 1.86? because I followed others’ method by reinstalling the 1.85 version

yes it works for me with 1.86 , but I’m working in dev container, not ssh

Bad, the way didn’t work in the SSH case. Anyway, thanks for your suggestion.

I have the same issue trying to connect with CentOS 7.7.1908 whose glibc version is 2.17. While just being stopped supporting by Red Hat, it’s not a wise choice to end its support for running VS Code server on this so widely installed Linux distribution. This has caused a huge impact on my workflow. Snipaste_2024-02-02_09-42-26

We have updated the minimum requirements for remote server as well, it is documented in https://aka.ms/vscode-remote/faq/old-linux. It should also show up in link from the notification or the server failure logs. Affected users please follow the workaround mentioned in the faq.

@orgads I will update the release notes.

@pftbest can you provide a minimal devcontainer configuration to repro your issue.

What a stupid upgrade, I lost most of my work day yesterday trying to make this work…

Thanks for all the suggestions here, I can now work again after downgrading to 1.85.2.

I think one of the bigger issues with that is, that at some point we can no longer install extension updates while being stuck 1.85.2 Imagine working with copilot. At some point a little API change in the client may need a little update to copilot. We are now stuck with all the extensions versions too…

same here

Downgrading to 1.85.2 works. What a silly upgrade.

What a stupid update. I wasted the middle of the day

mark. Downgrading solved my problem, urgently need a thorough solution

I found it is better to use the portable mode portable as you can still keep the 1.86.0 version for newer servers but only use the portable one for centos7

I’ve used this trick before attach and it helped https://github.com/microsoft/vscode/issues/203728

In bash shell, touch /tmp/vscode-skip-server-requirements-check Now from latest insiders, run Attach to running container and chose the above container Server setup will fail but make sure the logs contain the following statements !!! WARNING: Skipping server pre-requisite check !!! !!! Server stability is not guaranteed. Proceed at your own risk. !!!

But I do not understand what is wrong with my distro, Ububtu 11 it has “Debian GLIBC 2.31-13+deb11u7”

same here. please have a quick hotfix. a lot of centos 7 users around

so apparently the “hot fix” is to ask the server admins to upgrade their libs (which is really hard for them) the recommendations are always "Qu’ils mangent de la brioche"or “何不食肉糜”