Vscode-remote-release: Stuck on checking uname when attaching to remote container

[PALuczak]

• VSCode Version: 1.41.1
• Local OS Version: Windows 10 1903 18362.535
• Remote OS Version: 4.9.0-11-amd64 #1 SMP Debian 4.9.189-3+deb9u1 (2019-09-20) x86_64 GNU/Linux
• Remote Container version: tensorflow/tensorflow:latest-gpu-py3-jupyter
• Remote Extension/Connection Type: Docker over SSH

Steps to Reproduce:

1. Set docket.host to ssh://username@ip
2. Try to attach to a remote container

The Dev containers output at debug level logging looks like this:

[1 ms] Start: Resolving remote
[5 ms] Setting up container tfLab

[2345 ms] Start: Check Docker is running
[5115 ms] Stop (2770 ms): Check Docker is running
[5116 ms] Start: Inspecting container
[7759 ms] Stop (2643 ms): Inspecting container
[7785 ms] Start: Run in container: uname -m

Log in the developer tools:

console.ts:137 [Extension Host] (node:28384) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
t.log @ console.ts:137

[idengaurav]

I was facing the same issue. Here's how it worked for me.

• Uninstall vscode (It was installed using snap)
• Install using deb package if your'e on ubuntu.
• Install the remote container package.
• Add this to your settings "docker.host": "tcp://localhost:23751",
• Run this in a terminal : ssh -NL localhost:23751:/var/run/docker.sock username@host
• Now open vscode and check the container list and try connecting.

[amineHY]

I was facing the same issue. Here's how it worked for me.

* Uninstall vscode (It was installed using snap)

* Install using deb package if your'e on ubuntu.

* Install the remote container package.

* Add this to your settings "docker.host": "tcp://localhost:23751",

* Run this in a terminal : ssh -NL localhost:23751:/var/run/docker.sock username@host

* Now open vscode and check the container list and try connecting.

Hi @idengaurav , do you have any source for the proposed solution ?

[langaads]

i'm having the same issue on similar environment.

Running the container using a single docker file works, but when i try starting the same container using docker-compose it get stuck on uname -m

manually running docker-compose works.

[idengaurav]

I was facing the same issue. Here's how it worked for me.

* Uninstall vscode (It was installed using snap)

* Install using deb package if your'e on ubuntu.

* Install the remote container package.

* Add this to your settings "docker.host": "tcp://localhost:23751",

* Run this in a terminal : ssh -NL localhost:23751:/var/run/docker.sock username@host

* Now open vscode and check the container list and try connecting.

Hi @idengaurav , do you have any source for the proposed solution ?

No source. I tried this myself and it worked. For the ssh i found it in vs code container docs
Link here: https://code.visualstudio.com/docs/remote/containers-advanced#_developing-inside-a-container-on-a-remote-docker-host
Basically i just, uninstalled vscode that was installed from snap and installed from deb.

[chrmarti]

Using an SSH tunnel can serve as a workaround: https://code.visualstudio.com/docs/remote/troubleshooting#_using-an-ssh-tunnel-to-connect-to-a-remote-docker-host

(The snap and deb installs should behave the same.)

[marcpawl]

Same problem on a Mac, going to a Fedora box, running a Centos 7 container.
Version: 1.42.0-insider
Commit: cba31b819ea99836daf51cee56299348e9c6d20b
Date: 2020-01-08T05:35:29.477Z
Electron: 6.1.6
Chrome: 76.0.3809.146
Node.js: 12.4.0
V8: 7.6.303.31-electron.0
OS: Darwin x64 17.7.0

Remote-containers 0.96.0

basement:~ marcpawl$ docker -v
Docker version 19.03.5, build 633a0ea

Workaround using ssh tunnel as described above did not work for me.

[fvanmaele]

I had this issue because remoteUser in devcontainer.json did not match an existing user defined in the Dockerfile. Changing remoteUser to the correct user fixed the issue for me.

[AdemFr]

I don't know if this will help anybody, but I thought I'd leave it here.
Since VScode seems to build the devcontainer only once and tries to restore it afterwards (so all your extensions are still there I suppose), as soon as I managed to skrew up the devcontainer and it wouldn't start, all changes afterwards to the devcontainer.json would not take effect.

So for me the solution was to docker container prune before I tried to reopen the directory with the modified devcontainer.json config.

[chrmarti]

@AdemFr There is a Rebuild and Reopen command in the latest release of this extension for VS Code Insiders that will help in these cases. (Will be available in VS Code 1.42 if you don't want to use the Insiders version.)

[hastarin]

I just hit this with the new Docker Desktop (Windows) 2.2.0

Can anyone make it clear what they are changing in devcontainer.json?

[chrmarti]

@fvanmaele Thanks, setting remoteUser to a user that is not in the /etc/passwd nicely reproduces this case.

Is anyone seeing other cases where this fails?

I'll fix it by surfacing the error message that is currently lost.

[chrmarti]

The fix for logging errors is in the latest version 0.99.2 of the extension available for VS Code Insiders (https://code.visualstudio.com/insiders/). Could those still seeing issues retry with that and check if the Containers log has any additional information?

[PALuczak]

@chrmarti The issue still persists:

[1 ms] Start: Resolving remote
[4 ms] Setting up container tfLab

[315 ms] Start: Check Docker is running
[520 ms] Stop (205 ms): Check Docker is running
[521 ms] Start: Inspecting container
[762 ms] Stop (241 ms): Inspecting container
[790 ms] Start: Run in container: uname -m

And to clarify: this issue occurs when attaching to an existing remote container (in this case a Tensorflow compute box). I do not have a devcontainer.json file. My current workaround involves adding

    LocalForward 23750 /var/run/docker.sock

to my ssh config, connecting to the docker host using Remote - SSH and subsequently attaching to a container. The final window can be saved as a workspace in order to avoid repeating this rather tedious process. This workspace workaround also requires me to have a terminal with SSH session in the background.

Extension version: 0.99.2
Version: 1.42.0-insider (user setup)
Commit: c4b6a6b537de49a734d0eedea06152ea37dfdb6a
Date: 2020-01-28T05:38:41.922Z
Electron: 6.1.6
Chrome: 76.0.3809.146
Node.js: 12.4.0
V8: 7.6.303.31-electron.0
OS: Windows_NT x64 10.0.18362

[chrmarti]

@PALuczak Do you set the "remoteUser" in the devcontainer.json? If so: Please check that actually exists in the container's /etc/passwd.

[PALuczak]

@chrmarti As I said/wrote: I do not use a devcontainer.json file I am trying to attach to an existing container that is used for long running computations, the container is expected to run at all times.

[skyrpex]

I had the same issues for some devcontainers in Linux. The editor stucks on Start: Run in container: uname -m.

I've fixed it overriding the default command for the image used by the dev container, like this:

version: "3"

services:
  app:
    # Overrides default command so things don't shut down after the process ends.
    command: sleep infinity

Or if you use a Dockerfile directly:

CMD ["sleep", "infinity"]

[chrmarti]

@PALuczak Check if you have the docker CLI on your local PATH.

I will improve logging for that case too.

[PALuczak]

@chrmarti I have docker CLI in PATH on both my local machine (Win10) and the remote server (Ubuntu).

[chrmarti]

@PALuczak I have published version 0.101.0 with the logging fix. If you are running VS Code Insiders, could you give that a try and see if the log has any additional information now?

[PALuczak]

Run at log level Trace:

[0 ms] Start: Resolving remote
[3 ms] Setting up container tfLab

[235 ms] Start: Check Docker is running
[428 ms] Stop (193 ms): Check Docker is running
[429 ms] Start: Inspecting container
[649 ms] Stop (220 ms): Inspecting container
[665 ms] Start: Run in container: uname -m

the issue still persists on version 0.101.0

[chrmarti]

Fixed an issue where this would fail in a similar way when C:\Program Files or C:\Program Files\Docker is on the PATH. #2358

[chrmarti]

@PALuczak Could you give the latest version (0.102.0) a try? You currently need VS Code Insiders to get that: https://code.visualstudio.com/insiders/

[PALuczak]

@chrmarti After the latest update the issue continues to exist.

With run level Trace:

[0 ms] Start: Resolving remote
[2 ms] Setting up container tfLab

[293 ms] Start: Check Docker is running
[566 ms] Stop (273 ms): Check Docker is running
[569 ms] Start: Inspecting container
[919 ms] Stop (350 ms): Inspecting container
[990 ms] Start: Run: C:\Program Files\Docker\Docker\resources\bin\docker.exe exec -i -u 1000:1000 -e VSCODE_REMOTE_CONTAINERS_SESSION=7fe547a4-20d0-4442-a429-204c69521ffc1582277658403 791da3f79e3b122f2c7262339d4bdb000e3399b28febae39b598a33cb13effa6 /bin/sh
[1012 ms] Start: Run in container: uname -m

VScode:

Version: 1.43.0-insider (user setup)
Commit: e6a45f4242ebddb7aa9a229f85555e8a3bd987e2
Date: 2020-02-21T05:42:20.536Z
Electron: 7.1.11
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Windows_NT x64 10.0.18362

Extension:

Name: Remote - Containers
Id: ms-vscode-remote.remote-containers
Description: Open any folder inside (or mounted into) a container and take advantage of Visual Studio Code's full feature set.
Version: 0.102.0
Publisher: Microsoft
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers

[chrmarti]

@PALuczak Is your Dockerfile or your docker run ... setting the user to 1000:1000? What do you get when you run:

docker exec -it -u 1000:1000 <container_id> /bin/sh

with the current container id? Can you run uname -m in there?

[vscodebot[bot]]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[PALuczak]

I apologise for the delayed reply.

The full command used for creating the container is:
docker run --gpus all --restart unless-stopped -u $(id -u):$(id -g) -it -d -p 8880:8888 -p 6042:6042 --name tfLab -v ~/:/tf/mount/ tensorflow/tensorflow:latest-gpu-py3-jupyter

Running the command works fine:

~$ docker exec -it -u 1000:1000 tfLab /bin/sh
$ uname -m
x86_64
$ uname -a
Linux 791da3f79e3b 4.9.0-11-amd64 #1 SMP Debian 4.9.189-3+deb9u2 (2019-11-11) x86_64 x86_64 x86_64 GNU/Linux

Though I have now an additional issue: while the Docker extension can see all containers on the remote machine, the Remote - Containers gets stuck on trying to find them:

CommandService#executeCommand remote-containers.explorerTargetsRefresh
MainThreadTreeViews#$refresh targetsContainers undefined

Versions:

Id: ms-vscode-remote.remote-containers
Version: 0.112.0

Id: ms-azuretools.vscode-docker
Version: 1.0.0



md5-09a038281350f4db8b280c1a4fe15ddd



Version: 1.45.0-insider (user setup)
Commit: 4f05de82a75569601bc2dc894023383b4ce1c2c0
Date: 2020-04-13T17:53:50.995Z
Electron: 7.2.1
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Windows_NT x64 10.0.18363

[PALuczak]

I have also checked from a different machine in the same network, and the extension there works fine:

[0 ms] Start: Resolving remote
[2 ms] Setting up container /tfLab

[2 ms] Start: Run: docker inspect --type container /tfLab
[296 ms] Start: Check Docker is running
[296 ms] Start: Run: docker info
[691 ms] Start: Inspecting container
[691 ms] Start: Run: docker inspect --type container 791da3f79e3b122f2c7262339d4bdb000e3399b28febae39b598a33cb13effa6
[973 ms] Start: Run: docker exec -i -u 1000:1000 -e VSCODE_REMOTE_CONTAINERS_SESSION=1eacc5e8-5b63-4d39-9ff1-9f02152eb7d11586858384234 791da3f79e3b122f2c7262339d4bdb000e3399b28febae39b598a33cb13effa6 /bin/sh
[979 ms] Start: Run in container: uname -m
[1552 ms] x86_64
[1552 ms] 
[1552 ms] Start: Run in container: (cat /etc/os-release || cat /usr/lib/os-release) 2>/dev/null
[1555 ms] NAME="Ubuntu"
VERSION="18.04.3 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.3 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic
...
rest of the output omitted for brevity

So the issue cannot be with the network or the remote machine configuration.

Versions on the working machine:

Id: ms-vscode-remote.remote-containers
Version: 0.112.0

Version: 1.44.0 (user setup)
Commit: 2aae1f26c72891c399f860409176fe435a154b13
Date: 2020-04-07T23:31:18.860Z
Electron: 7.1.11
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Windows_NT x64 10.0.18363

[chrmarti]

Can you run F1 > Remote-Containers: Open Container Configuration File on the machine where it works and post its content here? Is there a similar file on the machine where it does not work?

[PALuczak]

The option Remote-Containers: Open Container Configuration File only appears once I attach to the container so it is impossible for me to do it on the machine with issues.

On the machine where it works all I get is:

{
    "workspaceFolder": "/tf/mount"
}

[chrmarti]

@PALuczak With #2758 solved, what is the status of this issue?

[PALuczak]

With docker.host set to ssh://username@alias this issue also appears to be fixed, once again thank you for the time spent working on this problem.

[chrmarti]

Great, thanks @PALuczak!