Open benoitf opened 1 month ago
The issue is actually more broad. What I faced when was implementing AF_UNIX sockets in addition to named pipes on Windows is that machine doesn't really know which endpoints were assigned during startup and the fact that they are owned by gvproxy process. So, the actually correct way would be to have some way to fetch the data from gvproxy - like inspecting command line of a running process (on macOS this will add the helper binary to the list).
Alternatively this information could be preserved in the machine config, while machine is running, but it doesn't feel right to use config for runtime data and currently there is no well organized store for the runtime data.
TL;DR there is no simple way of definitely say, which API endpoints were bound during machine startup using Podman CLI.
the only way to definitely do this is to limit Podman from running multiple machines on WSL. No other provider does this.
A friendly reminder that this issue had no activity for 30 days.
Feature request description
When starting podman machines, depending on the system configuration or the operating system, podman machine will also bind a socket to the system wide path (like /var/run/docker.sock) or
npipe:////./pipe/docker_engine
example on Windows code: https://github.com/containers/podman/blob/1ae4b047f62ce5171a74bfd6169d9e557a4b9842/pkg/machine/shim/networking_windows.go#L20-L22
But we don't know from CLI POV if has been taken or not.
For example on Windows, I can start 3 machines in a different order, and I would like to know which one has taken the
npipe:////./pipe/docker_engine
endpoint.when starting the machine, the information is being displayed in the output but if machines are started by scripts or GUI you don't find the information.
on macOS there is a workaround as the helper will create symlinks to
/var/run/docker.sock
. But it would be still nice to know using the CLI and not searching across symlinks if it has been taken or not.Suggest potential solution
A way to get that information using podman CLI.
could be inside
podman machine list --format=json
(orpodman machine inspect
or both or something else)Have you considered any alternatives?
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.