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:
- Start vscode
- 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
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)
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.
~/.vscode-server
I don’t understand, why this update so aggresive, totally break up my working pipeline.
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:
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:
and even no warning before upgrade
What a smart ass to make a decision like that!
workaround solution to bypass glibc version check:
remove
~/.vscode-server/*
and ssh to remote again (would fail again, but can help reinstall node env)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
skip prerequirement check; modify
~/.vscode-server/bin/<remote-id>/bin/helpers/check-requirements.sh
Addexit 0
at the beginning of this file.Thanks @yakouyang @PappeSister , I tried these steps:
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
But it looks like it refers to desktop, not remote development. @deepak1556?
Ubuntu 18.04 has glibc 2.27.
Reviving VsCode remote connections manual
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
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 onelibstdc++.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). Withlibstdcpp_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")
callingreadlink
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?Bad, the way didn’t work in the SSH case. Anyway, thanks for your suggestion.
It works for me.
I have the same issue trying to connect with CentOS
7.7.1908
whose glibc version is2.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.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
But I do not understand what is wrong with my distro, Ububtu 11 it has “Debian GLIBC 2.31-13+deb11u7”
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 “何不食肉糜”