Closed amaury-ml closed 1 year ago
Looks like it happens because vscode launches another server instance of the already running server. I'd recommend either 1- Allow the client attach to the currently running server 2- Kill the server when the # of clients drops to 0.
Anyway, it doesn't look like I'll see a fix soon, as I've seen no update on this one in 2 weeks The workaround is to kill all processes that relate to vscode-server every time a connection happen (when you change folder, or reconnect)
cc @tanhakabir
Hm it looks like we aren't able to resolve wget or curl in your container. Are you able to run wget --version
or curl --version
in your remote container? We run these commands to verify you have wget or curl available.
Sorry for not getting back to you... Yes, wget is present (see my original post), though I don't really know if the --version is available (though it should, I don't see why not). And I would LOVE to be able to tell you for sure, unfortunately my RPI was snatched from my desk and I won't get a new one any time soon (none are available for a reasonable price from a reasonable provider).
Ah that's unfortunate! Are you able to get one back in the future?
I really hope so. Those lil' buggers are a lot easier to use than most of the arm embedded systems I have to work on...
Hey there, got my device back online, and here's what I have for wget (curl is not installed)
(classic)XxRemoteUserxX@borabora:~$ wget --version
GNU Wget 1.19.4 built on linux-gnu.
-cares +digest -gpgme +https +ipv6 +iri +large-file -metalink +nls
+ntlm +opie +psl +ssl/openssl
Wgetrc:
/etc/wgetrc (system)
Locale:
/usr/share/locale
Compile:
gcc -DHAVE_CONFIG_H -DSYSTEM_WGETRC="/etc/wgetrc"
-DLOCALEDIR="/usr/share/locale" -I. -I../../src -I../lib
-I../../lib -Wdate-time -D_FORTIFY_SOURCE=2 -DHAVE_LIBSSL -DNDEBUG
-g -O2 -fdebug-prefix-map=/build/wget-ofwQt7/wget-1.19.4=.
-fstack-protector-strong -Wformat -Werror=format-security
-DNO_SSLv2 -D_FILE_OFFSET_BITS=64 -g -Wall
Link:
gcc -DHAVE_LIBSSL -DNDEBUG -g -O2
-fdebug-prefix-map=/build/wget-ofwQt7/wget-1.19.4=.
-fstack-protector-strong -Wformat -Werror=format-security
-DNO_SSLv2 -D_FILE_OFFSET_BITS=64 -g -Wall -Wl,-Bsymbolic-functions
-Wl,-z,relro -Wl,-z,now -lpcre -luuid -lidn2 -lssl -lcrypto -lpsl
ftp-opie.o openssl.o http-ntlm.o ../lib/libgnu.a
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://www.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.
Originally written by Hrvoje Niksic <hniksic@xemacs.org>.
Please send bug reports and questions to <bug-wget@gnu.org>.
Also, FYI, ubuntu core is very limited, and one has to run sudo classic
to get to the usual environment (bash + ubuntu installer apt + ...) But my .bashrc does exactly that for me (so I'm always in the classic mode).
[ -z $debian_chroot ] && sudo classic || echo "'sudo classic' or 'sudo SUDO_USER=root classic' to install something... Good to go!"
And if it was missed the 1st time, the whole thing works fine until a change of folder or a disconnect/reconnect happen and it needs to connect to the running vscode server. Though the 1st install happen via an scp (not wget but it could be due to my network config)
I just noticed that you may not use ssh user@blah (or you may specify the shell to use) when setting up things (though not the 1st time) and the sudo classic may not be executed at all. In that case, wget does not exist (if I remove the line from by bahrc that does sudo classic
, wget
is not available, but I do have a wget-snap
available. Yeah, I know... still learning ubuntu core myself and how to use containers...
Hm I see. I'm also not super familiar with Ubuntu Core. Are you able to run the following?
echo "wget --version" | ssh -T -D 56318 rpi bash
Nope, and that's the problem I guess
$ ssh rpi "wget --version"
bash: wget: command not found
$ ssh rpi "wget-snap --version"
GNU Wget 1.20.3 built on linux-gnu.
Yeah that seems like the issue. Your environment on initial connection doesn't seem to have wget so our script fails. I can investigate if we can use wget-snap as well
Or make the tool be settable by the user (wget or curl or.... ), and its path.
Now it should also fall back to download locally
Here is the trace I have when I try to remote ssh in VS code from a win10 system:
As far as I know it used to work fine and I cannot remember if there was an update or something in the last 2 to 3 days, but it simply stopped working. The remote system is an Ubuntu Core running ubuntu 18.04 in a container. Nothing that different from a user standpoint. And yes, wget is intalled:
(classic)XxRemoteUserxX@rpi:~$ which wget /usr/bin/wget (classic)XxRemoteUserxX@rpi:~$ dpkg -l | grep -w wget ii wget 1.19.4-1ubuntu2.2 arm64 retrieves files from the web
And a simple ssh into the linux host goes straight to a 'sudo classic' to jump to the container.
Now, if I go and remove ~/.vscode-server, it will reinstall, via scp from the win10 host (sorry, no debug trace, as it's not visible, and succeeds, so it disappears), and it works... until I go open a folder, and then it VS code tries to reinstall the server for some reason and that when it complains.