-
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 4.0 hangs indefinitely if ipv6 is disabled on system #13388
Comments
@jewthon You got it, feel free to ping me if you need help. |
We need this pretty quick though, I have a feeling a lot of users do this. Especially in security consious locations where they don't use IPV6 |
shouldn't this be implemented in netavark ? |
no this is a slirp4netns ipv6 hack |
the workaround is to set |
If you include an error handling function in the errorhandlingfile in pkg
section and include there that whenever that type of warning comes give an
error message . Is this implementation ok ?
…On Tue, Mar 8, 2022, 7:47 PM Paul Holzinger ***@***.***> wrote:
the workaround is to set network_cmd_options = [] under the [engine]
section in ~/.config/containers/containers.conf
—
Reply to this email directly, view it on GitHub
<#13388 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AWGMRINOGDY6JT4GU4WOHB3U65OQ5ANCNFSM5PUWKHBQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
You should ignore ENOENT here: podman/libpod/networking_slirp4netns.go Line 321 in acfcecf
But the more important part is to fix the hang, the way how slirpReadyChan is completely broken. It also does not actually check that the sysctl is set before we start slirp4netns. So I think fixing the synchronization is more complicated.
|
user has reported this again on irc; any progress? |
Not yet . I have tried . But couldn't. Sorry
…On Fri, Mar 11, 2022, 8:24 PM Brent Baude ***@***.***> wrote:
user has reported this again on irc; any progress?
—
Reply to this email directly, view it on GitHub
<#13388 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AWGMRIJO3W57BU2D2OLBC5LU7NNDRANCNFSM5PUWKHBQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
I will fix it. |
#13485 should fix it. It would be great if someone could test this on a system with ipv6 disabled. |
When enable_ipv6=true is set for slirp4netns (default since podman v4), we will try to set the accept sysctl. This sysctl will not exist on systems that have ipv6 disabled. In this case we should not error and just ignore the extra ipv6 setup. Also the current logic to wait for the slirp4 setup was kinda broken, it did not actually wait until the sysctl was set before starting slirp. This should now be fixed by using two `sync.WaitGroup`s. [NO NEW TESTS NEEDED] Fixes containers#13388 Signed-off-by: Paul Holzinger <pholzing@redhat.com>
When enable_ipv6=true is set for slirp4netns (default since podman v4), we will try to set the accept sysctl. This sysctl will not exist on systems that have ipv6 disabled. In this case we should not error and just ignore the extra ipv6 setup. Also the current logic to wait for the slirp4 setup was kinda broken, it did not actually wait until the sysctl was set before starting slirp. This should now be fixed by using two `sync.WaitGroup`s. [NO NEW TESTS NEEDED] Fixes containers#13388 Signed-off-by: Paul Holzinger <pholzing@redhat.com>
When enable_ipv6=true is set for slirp4netns (default since podman v4), we will try to set the accept sysctl. This sysctl will not exist on systems that have ipv6 disabled. In this case we should not error and just ignore the extra ipv6 setup. Also the current logic to wait for the slirp4 setup was kinda broken, it did not actually wait until the sysctl was set before starting slirp. This should now be fixed by using two `sync.WaitGroup`s. [NO NEW TESTS NEEDED] Fixes containers#13388 Signed-off-by: Paul Holzinger <pholzing@redhat.com>
When enable_ipv6=true is set for slirp4netns (default since podman v4), we will try to set the accept sysctl. This sysctl will not exist on systems that have ipv6 disabled. In this case we should not error and just ignore the extra ipv6 setup. Also the current logic to wait for the slirp4 setup was kinda broken, it did not actually wait until the sysctl was set before starting slirp. This should now be fixed by using two `sync.WaitGroup`s. [NO NEW TESTS NEEDED] Fixes containers#13388 Signed-off-by: Paul Holzinger <pholzing@redhat.com>
When enable_ipv6=true is set for slirp4netns (default since podman v4), we will try to set the accept sysctl. This sysctl will not exist on systems that have ipv6 disabled. In this case we should not error and just ignore the extra ipv6 setup. Also the current logic to wait for the slirp4 setup was kinda broken, it did not actually wait until the sysctl was set before starting slirp. This should now be fixed by using two `sync.WaitGroup`s. [NO NEW TESTS NEEDED] Fixes containers#13388 Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
Podman 4.0.1 will hang indefinitely with this warning if ipv6 is disabled on the system:
Steps to reproduce the issue:
disable ipv6 (e.g. with kernel parameter
ipv6.disable=1
podman run --rm hello-world
Describe the results you received:
podman doesn't run the simple hello-world container
Describe the results you expected:
podman to run the container. I expect that warnings don't hang the application, anything that is required and missing should be an error, not a warning. I also expect podman to actually work without ipv6 enabled :)
Additional information you deem important (e.g. issue happens only occasionally):
happens every time on an Alpine Linux host. podman 3.x did not have this issue
Output of
podman version
:Output of
podman info --debug
:Package info (e.g. output of
rpm -q podman
orapt list 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.):
Alpine Linux Edge, x86_64,
linux-lts
kernel @ 5.15.24strace output: strace.log
The text was updated successfully, but these errors were encountered: