Open Folder in Container doesn't like wrapper script

[rjra100]

Type: Bug

As of VSCode 1.92, I'm seeing a "Docker returned an error" dialog saying "Make sure the Docker daemon is running." pop up immediately when doing Open Folder in Container. According to the log, it's trying to check the docker version:

[359181 ms] Start: Run: docker version --format {{json .}}

No further output is reported.

I strongly suspect that the problem is that my Windows docker is in fact a docker.bat invoking Docker itself in WSL (content is @wsl --exec docker %*), and that it's failing for the same reason as this issue: NodeJS 20.12.2 now requires all attempts to spawn a batchfile to pass shell: true and otherwise fails with EINVAL. Any chance that could be added to the Docker version check call? It'd also be a good idea to actually report the error message if that call fails - even with logging set to Trace level, I'm not seeing any indication of the actual error.

It's possible to work around it by opening the folder in VSCode and then doing "Reopen in Container", but that clutters up my recents list, so I'd prefer to be able to open directly :)

Extension version: 0.380.0 VS Code version: Code 1.92.0 (b1c0a14de1414fcdaa400695b4db1c0799bc3124, 2024-07-31T23:26:45.634Z) OS version: Windows_NT x64 10.0.19045 Modes: Remote OS version: Linux x64 5.15.153.1-microsoft-standard-WSL2 Remote OS version: Linux x64 4.18.0-372.80.1.el8_6.x86_64

System Info

|Item|Value| |---|---| |CPUs|Intel(R) Core(TM) i9-10980XE CPU @ 3.00GHz (36 x 3000)| |GPU Status|2d_canvas: enabled
canvas_oop_rasterization: enabled_on
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
skia_graphite: disabled_off
video_decode: enabled
video_encode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled
webgpu: enabled
webnn: disabled_off| |Load (avg)|undefined| |Memory (System)|127.80GB (48.23GB free)| |Process Argv|| |Screen Reader|no| |VM|0%| |Item|Value| |---|---| |Remote|WSL: Ubuntu-22.04| |OS|Linux x64 5.15.153.1-microsoft-standard-WSL2| |CPUs|Intel(R) Core(TM) i9-10980XE CPU @ 3.00GHz (36 x 0)| |Memory (System)|62.69GB (60.36GB free)| |VM|0%| |Item|Value| |---|---| |Remote|SSH: qfdfrm-pw-698| |OS|Linux x64 4.18.0-372.80.1.el8_6.x86_64| |CPUs|Intel Core Processor (Broadwell) (16 x 0)| |Memory (System)|188.64GB (180.92GB free)| |VM|0%|

[rjra100]

Ah - found the missing output in the "Window" Output pane. Sorry! Anyway, think this confirms my diagnosis:

2024-08-07 11:21:17.760 [error] [Extension Host] Error: spawn EINVAL
    at ChildProcess.spawn (node:internal/child_process:421:11)
    at Object.spawn (node:child_process:799:9)
    at c:\Users\ralexander72\.vscode\extensions\ms-vscode-remote.remote-containers-0.380.0\dist\extension\extension.js:126:1646
    at async se (c:\Users\ralexander72\.vscode\extensions\ms-vscode-remote.remote-containers-0.380.0\dist\extension\extension.js:125:494)
    at async rL (c:\Users\ralexander72\.vscode\extensions\ms-vscode-remote.remote-containers-0.380.0\dist\extension\extension.js:293:1573)
    at async Yy (c:\Users\ralexander72\.vscode\extensions\ms-vscode-remote.remote-containers-0.380.0\dist\extension\extension.js:384:4832)
    at async to (c:\Users\ralexander72\.vscode\extensions\ms-vscode-remote.remote-containers-0.380.0\dist\extension\extension.js:384:1268)
    at async jU (c:\Users\ralexander72\.vscode\extensions\ms-vscode-remote.remote-containers-0.380.0\dist\extension\extension.js:412:23099)
    at async d.h (c:\Users\ralexander72\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:154:206473)

[rjra100]

Related issues:

• https://github.com/microsoft/vscode-remote-release/issues/10061 (same problem in Remote-SSH)
• https://github.com/microsoft/vscode/issues/224184 (same problem launching debugger)

[rjra100]

This clearly isn't getting any love. For what it's worth, in our case we no longer need the wrapper script anyway - fixed by setting "dev.containers.executeInWSL": true instead.