Failed to attach VSCode

[st-schneider]

Issue Type: Bug

I tried to connect to a container and got this.

[19 ms] Start: Resolving remote
[21 ms] Setting up container /abc_1

[22 ms] Start: Run: docker inspect --type container /abc_1
[97 ms] Start: Check Docker is running
[97 ms] Start: Run: docker info
[236 ms] Start: Inspecting container
[237 ms] Start: Run: docker inspect --type container 2240ab93c87a7dde9c888f39f75ac13a18e7da67d5f4a6e27f3799069505843a
[324 ms] Start: Run: docker exec -i -u root -e VSCODE_REMOTE_CONTAINERS_SESSION=675ff1d2-de77-4236-841e-5de4590e17901593252242021 2240ab93c87a7dde9c888f39f75ac13a18e7da67d5f4a6e27f3799069505843a /bin/sh
[329 ms] Start: Run in container: uname -m
[468 ms] x86_64
[469 ms] 
[469 ms] Start: Run in container: (cat /etc/os-release || cat /usr/lib/os-release) 2>/dev/null
[474 ms] NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.8.0
PRETTY_NAME="Alpine Linux v3.8"
HOME_URL="http://alpinelinux.org"
BUG_REPORT_URL="http://bugs.alpinelinux.org"
[474 ms] 
[474 ms] Start: Run in container: cat /etc/passwd
[480 ms] Start: Run in container: test -d /root/.vscode-server-insiders
[483 ms] 
[483 ms] 
[483 ms] Start: Run in container: set -o noclobber ; mkdir -p '/root/.vscode-server-insiders/data/Machine' && { > '/root/.vscode-server-insiders/data/Machine/.writeMachineSettingsMarker' ; } 2> /dev/null
[485 ms] 
[486 ms] 
[486 ms] Exit code 1
[486 ms] 
Support for Alpine Linux is in preview.

[486 ms] Start: Run in container: test -d /root/.vscode-server-insiders/bin/6c235c723cb2d8defb840f732eac620f54aa8b9d
[488 ms] 
[488 ms] 
[488 ms] Exit code 1
[488 ms] Installing VS Code Server for commit 6c235c723cb2d8defb840f732eac620f54aa8b9d
[488 ms] Start: Run in container: mkdir -p /root/.vscode-server-insiders/bin/6c235c723cb2d8defb840f732eac620f54aa8b9d_1593252243971
[491 ms] 
[491 ms] 
[493 ms] Start: Run in container: apk info | grep -e '^libstdc++$' || (apk update && apk add libstdc++)
[698 ms] libstdc++
[698 ms] 
[698 ms] Start: Run in container: (dd iflag=fullblock bs=8192 count=3803 2>/dev/null; dd iflag=fullblock bs=7171 count=1 2>/dev/null) | tar --no-same-owner -xz --strip-components 1 -C /root/.vscode-server-insiders/bin/6c235c723cb2d8defb840f732eac620f54aa8b9d_1593252243971
[704 ms] 
[704 ms] tar: invalid magic
tar: short read
[704 ms] Exit code 1
[708 ms] Command in container failed: (dd iflag=fullblock bs=8192 count=3803 2>/dev/null; dd iflag=fullblock bs=7171 count=1 2>/dev/null) | tar --no-same-owner -xz --strip-components 1 -C /root/.vscode-server-insiders/bin/6c235c723cb2d8defb840f732eac620f54aa8b9d_1593252243971

Extension version: 1.3.1
VS Code version: Code - Insiders 1.47.0-insider (6c235c723cb2d8defb840f732eac620f54aa8b9d, 2020-06-26T05:33:20.679Z)
OS version: Darwin x64 18.7.0

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz (8 x 2800)
GPU Status	2d_canvas: enabled flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on oop_rasterization: disabled_off opengl: enabled_on protected_video_decode: unavailable_off rasterization: enabled skia_renderer: disabled_off_ok video_decode: enabled viz_display_compositor: enabled_on webgl: enabled webgl2: enabled
Load (avg)	4, 4, 5
Memory (System)	16.00GB (1.00GB free)
Process Argv
Screen Reader	no
VM	0%

[chrmarti]

Maybe the server tar is corrupt. Does deleting $TMPDIR/vsch/6c235c723cb2d8defb840f732eac620f54aa8b9d/vscode-server-linux-alpine.tar.gz help?

[st-schneider]

I don't have that folder.

[chrmarti]

Maybe you since updated VS Code Insiders, the path includes the VS Code commit id. Is there anything in $TMPDIR/vsch?

[st-schneider]

No there isn't.

[chrmarti]

I'm assuming you're on Mac, is that correct? Is your temp folder somewhere else? There should be a vsch folder in the temp folder. We create that when the extension downloads the server tar and the log you posted suggests that we are past that point. 🤔

[st-schneider]

Well you don't have to assume since the OS Version gives it away ;) Does the Insiders thing cache it somewhere else or in a different temp folder?

[st-schneider]

Did a full search now and found it here, no env variable for that I think.
/private/var/folders/h9/jcbj_l1j00ngxqz4j97k09dc165jf5/T/vsch/376d9d9d785ccca128fdbb16f001446d0ad64d32

[st-schneider]

Deleting it doesn't seem to change anything.

[chrmarti]

Reproduced with Alpine 3.8, it works with Alpine 3.9. Given that Alpine 3.8 is no longer supported by Alpine Linux itself, can you upgrade to at least 3.9? /fyi @Chuxel

[chrmarti]

For background: Alpine 3.8's dd does not support iflag=fullblock which is the only way for us to make sure we get the entire server piped to tar before dd closes its stdin and we continue with sending commands to the invoking shell.

[st-schneider]

How did it work before? Because it did work before.

[st-schneider]

Ok I just updated the version inside the container. And then it seems to work.

[chrmarti]

I was using a separate docker exec to copy and untar the server before. Doing it through the existing connection saves some time.

[chrmarti]

@Chuxel Can we increase the min version for Alpine to 3.9?

A fix would check if we are using Alpine 3.8 and then fall back to using a separate docker exec per file transferred (text files could again use a heredoc as a fallback). Increasing the min version seems preferable at the moment given the additional complexity of the fix.

[Chuxel]

@chrmarti 3.8 just went out of support last month, so while not ideal, we can probably do that if the fix is huge. One of the general challenges with Alpine vs. even Debian (let alone Ubuntu) is how quickly it updates and deprecates. It's very much a "push to edge" distro. Perhaps we should have a "min" and "latest" test for Alpine to find problems... it seems to break more often than other distros. It's really only if Node no longer supports the distro that we seem to hit challenges with the Debian/RHL distro tree.

[Chuxel]

@chrmarti microsoft/vscode-docs#3849 and also updated README for next time we do a release

[chrmarti]

@Chuxel Great, thanks. What would the "latest" test do?

Looking into adding a "min" test for this release.

[Chuxel]

@chrmarti alpine:latest - checks for breaks in new versions as they land. e.g. 3.12 was released on 5/29.

[chrmarti]

@Chuxel Got it, I was think about a version check during startup. Preparing a PR.

[chrmarti]

Also updated the single container tests to run against debian:9 and alpine:3.9 in addition to debian:latest and alpine:latest.

[roblourens]

This doesn't appear to be published yet, can't verify

[chrmarti]

(Only the change to the tests did not go into the release.)

Verification:

• Start Alpine 3.8 and 3.9 containers:

docker run -d --name alpine3.8 alpine:3.8 sleep 999999
docker run -d --name alpine3.9 alpine:3.9 sleep 999999

• Attach to each from the Remote-Explorer.
  • Verify attaching to Alpine 3.8 fails with an error dialog saying Alpine 3.9 is required.
  • Verify attaching to Alpine 3.9 works.
• Remove containers:

docker rm -f alpine3.8
docker rm -f alpine3.9