-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
podman generated remote connections may fail from possible mismatch between "localhost" and 127.0.0.1 listener #16470
Comments
Do you have a gvproxy process running and does it listen on the mentioned port? |
It seems so.
|
Had the same problem, I had to create a new machine and then
Solved the problem. |
@benfay88 Thank you for reply. Unfortunately, in my case it did not change anything. |
@uaru Can you manually change the ssh host url in |
@Luap99 I had this problem, and your suggested change to the config from localhost to 127.0.0.1 worked. I did delete the machine and reinitialized it via the desktop app and it worked. MacOS Ventura 13.0.1 running on M1 Max Ultra |
@Luap99 Thank you. Your hint worked.
|
Thanks @Luap99, one annoying thing I noticed is that if I destroy the machine and recreate it, then this will be created again with |
For me, changing
Update |
A friendly reminder that this issue had no activity for 30 days. |
In my case, I used Podman Desktop which created a new machine. I listed the machines ( |
This does not resolve OPs issue, but may resolve others. Folks, remember to follow the machine start prompts, if applicable: This is Macbook M1 Max
Once I added the system helper service I have had zero issues with pulling/running containers. |
On Windows I reproduce the same error. podman machine stop otherwise podman won't start again. I have to repeat this steps once every 2-3 days ... |
And there is no ./.config/containers/containers.conf in my user folder |
I have this exact same issue as well. |
@baude @ashley-cui @Luap99 @n1hility WDYT? |
This command doesn't seem to be working. Could you tell how did you install it ? |
I think folks might be reporting multiple different issues against this issue. The mac helper pertains only to Docker API clients, so anything using the REST interface. The podman CLI talks directly to podman machine over ssh. The OP is describing a failure on the latter case. If this latter case with the podman cli is happening it implies something is wrong with the connection configuration. You can access this with “podman system connection ls” The key and port of the default marked connection value should match the values returned from podman machine info / ls. |
In my case manually replacing However, recently I could not restart the podman machine (just hanged indefinitely), and in the end, I was forced to recreate the machine (delete and create). Doing it I faced the same problem again, having to manually correct the config file again. So clearly something is wrong with the way how default configuration is generated. The solution in #16579 is not a real solution, but a workaround. It is good that it works and I would agree it is not a high priority, but I think it cannot be called a final solution if out-of-the-box installation has to be tweaked by removing something manually and then adding something. |
/assign |
View reserved ports:
Add excluded reserved port:
|
For those on mac that are seeing the change of localhost -> 127.0.0.1 working? Could you paste the following:
@rhatdan @Luap99 I took a look and gvproxy is hardcoded to bind 127.0.0.1 yet we generate our client configs to use localhost. I suspect some mac configs (perhaps most recent installs) are now preferring ::1 in the host db, so that leads to a mismatch. Possible solutions would be generating config to match or dual binding a second listener on ::1 |
I haven't hit this problem yet, but FWIW here is what's returned from my 13.2.1 M1:
|
I would just code the config to use 127.0.0.1, seems simpler than having to deal with two listeners. |
in my case on windows using v4.4.4
just stopped default machine the above worked in my case. maybe default machine in a funky state? |
This is on Windows after a recent OS upgrade. I was using a 4.x which worked at some point. Returning to it today, it did not. I tried to stop/start the machine, remove the folders as advised, upgrade to 4.5, and lots of other things. Even rebooting, assuming somehow WSL networking is messed up. I am getting this:
Looking at this:
I am not sure, if I should not have 4.5 for the engine as well. I had tried to delete it in WSL with Can anybody confirm or deny that these versions ought to be identical? |
We have currently no way of making sure that the versions are equal, the VM image just uses standard fedora versions so it is expected that there is some drift. This shouldn't cause any issues here. |
Ok, just for completeness sake. Downgrading to 4.4.4 on the outside didn't change it. I had installed it also on a Windows 11 laptop, and there is also stopped working. I am pretty sure, Windows updates are breaking it somehow for me. I cannot be the only one, can I. |
@kayhayen I think there is an issue with the run command you are passing, |
@n1hility you are spot on, that is not how it works indeed. Shame on me and sorry for the noise. |
I have been trying to get I am getting the original problem
and one thing I notice after cleaning things up like remove and init podman is this:
so I did the following to change which VM to issue podman commands against
and then
|
@jeremycaine just a small tip, you can also do -c after podman if you switch frequently and don't want to change the default (e.g. |
Just want to add my 5 cents. Want to switch to podman from docker.
From the looks of it, I don't think it's anything networking related. My working theory is, something in the machine itself breaks/freezes if left running for a couple of days, which is why a restart fixes it. Maybe when the computer goes to sleep. |
First of all everyone keeps commenting with different kind of issues. The symptom may be similar but there are definitely different kind of problems reported here. Pleas look at the error messages carefully. Based on my #16470 (comment) this seems to be one problem which is easily fixed. The error message for this is And to everyone please stop hijacking existing issues with your problems, unless the error is the same or you are actually sure this is the same issue please just create a new separate issue. I triage almost all issues here. It is much simpler for me to close them as duplicates when they are actually are the same issue and link them the the correct ones. This allows users and developers to properly debug issues and not getting side tracked all the time by other unrelated comments. |
@Luap99 took a shot at a more specific subject line hoping it might help encourage new issue opens for other problems |
gvproxy listens on 127.0.0.1, using localhost as hostname can result in the client trying to connect to the ipv6 localhost (`::1`). This will fail as shown in the issue. This switches the hostname in the system connection to 127.0.0.1 to fix this problem. I switched the qemu, hyperV and WSL backend. I haven't touched the applehv code because it uses two different ips and I am not sure what is the correct thing there. I leave this to Brent to figure out. [NO NEW TESTS NEEDED] [1] https://github.com/containers/gvisor-tap-vsock/blob/main/cmd/gvproxy/main.go#L197-L199 Fixes containers#16470 Signed-off-by: Paul Holzinger <[email protected]>
Hi Team everyone is facing same issue can you please someone provide the resolution for this. |
Little gotcha, that if you run podman machine in rootful mode then you should name the root connection in the command like
|
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
podman cannot create connect to the machine
Steps to reproduce the issue:
brew install podman
podman machine init
Describe the results you received:
Describe the results you expected:
Additional information you deem important (e.g. issue happens only occasionally):
There is almost identical issue with previous version: #12728
But is still does not work.
I did try recreate the machine and
unset SSH_AUTH_SOCK
- it did not work.Ironically, I was able to run
docker-compose up -d
, only with the issue that it did not accepted environment variables.Output of
podman version
:Output of
podman info
:Package info (e.g. output of
rpm -q podman
orapt list podman
orbrew info podman
):Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)
Yes
Additional environment details (AWS, VirtualBox, physical, etc.):
MacBook M1 macOS 12.6.1
The text was updated successfully, but these errors were encountered: