Cant see any containers, nor images, yet many are running #3821
Comments
|
@PeterHric do any of the panels show an error message? What output do you get from these commands? |
|
This is what I see.. Docker version 20.10.17, build 100c70180 $ docker ps docker image ls --no-trunc --all --format "{{ json . }}" |
|
docker container ls --no-trunc --all --format "{{ json . }}" |
|
Thanks @PeterHric! Do you have a value for the VSCode setting |
|
Seems not: Ctrl+Shift+P -> docker.environment |
|
@PeterHric Can you check the extension settings (Ctrl+, by default or Ctrl+Shift+P > Preferences: Open Workspace Settings) as well? You can search for docker.environment there and it should show you if any are set. You may need to check for both the User and Workspace tabs to make sure. |
|
|
|
|
|
@PeterHric there's definitely no extension specific environment overrides then. Can you run the command |
|
Oh, come on.. Does this have end somewhere ? |
|
I understand the frustration; unfortunately there are a lot of different potential configurations between the OS, Docker, VSCode, and the Docker extension that could all lead to a behavior like this. Specifically, based on the behavior you're seeing, when you run docker commands from your terminal, it's executing them against one Docker environment (where your images and containers are running), while when we spawn a docker command from the extension, it's running against a different runtime environment (and therefore we're not seeing any images/containers). This could be a matter of different environment variables being applied to the terminal and the VSCode process (differences in PATH or DOCKER_HOST would be one possible culprit and the settings you checked are an additional configuration point where the extension can override those environment variables). Docker context is another configuration point where Docker can be setup to talk to different runtime endpoints and if any are configured, it's possible VSCode is using a different one by default or configuration. Bash/sh configurations could also cause different behavior for a command run from the terminal vs. a process spawned from vscode. Beyond that, SSH remoting is another scenario where the terminal and VSCode might be running commands against entirely different machines. There are other increasingly less likely (and increasingly harder to diagnose) scenarios beyond those that could also be a root cause. Because of how many different possible causes there are, the only real way to track down the root cause is to check the various possible settings/configurations that could be contributing until a source of the discrepancy is found. We'd be happy to keep suggesting additional troubleshooting steps if you decide you want to try anything else, but completely understand wanting to try a full re-install to see if that resolves the issue. |
|
docker context ls
|
|
@PeterHric The fact that Just to make sure, are you running VSCode in a remoting configuration (connecting to a remote machine via the SSH remoting extension for development)? If everything is running locally, can you run |
|
I'm facing the same issue. I'm running vscode in Linux Mint inside VirtualBox though. |
|
@TonyNyagah are your using any of the VSCode remoting features (SSH remoting extension, etc.) to connect to a remote machine? Also, can you run the command |
|
Nope, I am using it locally @thinkpad T430
Else, I'd mention it..
***@***.***:~/Projects/R$ ps aux | grep containerd
root 1216 0.0 0.0 1575952 7732 ? Ssl feb06 1:45
containerd --config /run/snap.docker/containerd/containerd.toml --log-level
error
peter 177050 0.0 0.0 11568 2664 pts/2 S+ 21:47 0:00 grep
--color=auto containerd
***@***.***:~/Projects/R$
|
|
@PeterHric Okay, I think I've finally managed to reproduce the issue and get some understanding around it. This seems to specifically be an issue with access to stdout being blocked by the snap sandbox when invoking one snap application (docker) from another (VSCode). It's going to take quite a bit more digging to figure out how we can fix this particular problem in the long term as the snap sandboxing isn't something we directly control, but you should be able to workaround it by setting the "Docker Path" property in the VSCode settings to |
|
The solution proposed by @danegsta works perfectly. |
|
I'll resolve this issue as a dupe of #3843, so users can easily find the solutions in that issue. |
Type: Bug
I have logged into my docker hub account, run docker compose up, which had downloded all necessary images, run them and now everything is up and running. Yet, I do not see any of those mentioned in the title.
Likewise:
No networks, neither volumes visible - yet I have several up and running..
Looks like it can't connect to the active docker daemon ??
However:
I do see everything correctly in the registries pane...
I also can not pull image from docker hub: "Process exited with code 1"
Extension version: 1.23.3
VS Code version: Code 1.74.3 (97dec172d3256f8ca4bfb2143f3f76b503ca0534, 2023-01-09T16:57:40.428Z)
OS version: Linux x64 5.4.0-137-generic snap
Modes:
Sandboxed: No
System Info
canvas_oop_rasterization: disabled_off
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: disabled_software
multiple_raster_threads: enabled_on
opengl: disabled_off
rasterization: disabled_software
raw_draw: disabled_off_ok
skia_renderer: enabled_on
video_decode: disabled_software
video_encode: disabled_software
vulkan: disabled_off
webgl: unavailable_software
webgl2: unavailable_software
webgpu: disabled_off
A/B Experiments
The text was updated successfully, but these errors were encountered: