-
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
Temporary failure in name resolution for service name when using docker compose with podman #24566
Comments
Can you provide the full error output? It is not clear to me what the expect error situation is. This seems to work for me using podman from main
|
One thing to note here AFAICT both containers are created and started in parallel by compose so there is no dependency as such if the dnstest container is created and started before the database is running it would not resolve the name. |
Oops, I guess i left out the depends_on part when trying to minimize this but the actual use case has that bit. |
Ok I managed to reproduce it. The key seems to be to have another container with dns running before, i.e.
Then your reproducer seem to work, I don't really know of any 5.3network chnages that would affect this but I guess I try to bisect it. |
I think this is a upgrade issue. The new version causes a nil deref as it is expecting data to be written on rootless-netns setup that was not written with 5.2. I will submit a fix for the nil deref but it is best to restart in order to get the new functionality of host.containers.internal (https://blog.podman.io/2024/10/podman-5-3-changes-for-improved-networking-experience-with-pasta/) Simple reproducer using 5.2.5 and podman 5.3.0 as bin/podman
|
In theory RootlessNetnsInfo() should never return nil here. However that was actually only true when the rootless netns was set up before and wrote the right cache file with the ip addresses. Given this cache file is a new feature just added in 5.3 if you updated from 5.2 or earlier the file will not exists thus cause failures for all following started containers. The fix for this is to stop all containers and make sure the rootless-netns was removed so the next start creates it new with the proper 5.3 cache file. However as there is no way to rely on users doing that and it is also not requirement so simply handle the nil deref here. The only way to test this would be to run the old version then the new version which we cannot really do in CI. We do have upgrade test for that but they are root only and likely need a lot more work to get them going rootless but certainly worth to explore to prevent such problems in the future. Fixes: a1e6603 ("libpod: make use of new pasta option from c/common") Fixes: containers#24566 Signed-off-by: Paul Holzinger <pholzing@redhat.com>
I can confirm that an upgrade to 5.3.0 followed by a reboot does not exhibit the problem anymore. Thank you for the quick help. |
Issue Description
A docker-compose file that worked fine on podman 5.2.5 (and works fine again when downgrading to 5.2.5) is broken on 5.3.0 because the service gets a reproducible "Temporary failure in name resolution" error when trying to lookup the database container name.
Steps to reproduce the issue
Steps to reproduce the issue
Describe the results you received
With DNS lookups in 5.3.0 I get an error when looking up one of the names of other services in the docker-compose.yml
Describe the results you expected
With DNS lookups in 5.2.5 I do get the hostname resolved to the IP of the container as I would expect.
podman info output
Podman in a container
No
Privileged Or Rootless
Rootless
Upstream Latest Release
Yes
Additional environment details
No response
Additional information
No response
The text was updated successfully, but these errors were encountered: