Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
Starting rhel9 docker container in rhel7.6 (vm) will resolve in container that is unable to resolve with "getaddrinfo() thread failed to start".
Version-Release number of selected component (if applicable):
rhel7.6
docker-1.13.1-101.git61c8524.el7.x86_64
kernel-3.10.0-957.10.1.el7.x86_64
How reproducible: always
Steps to Reproduce:
1. rhel7.6-vm# docker run -ti --rm --hostname test registry-proxy.engineering.redhat.com/rh-osbs/ubi9:9.0.0beta-476 /bin/bash
2. container# curl http://www.redhat.com
Actual results: getaddrinfo() thread failed to start", no rosolving
Expected results: address resolved
Additional info:
gitlab-runner-1 is rhel7.6 vm.
> [root@gitlab-runner-1 ~]# host www.redhat.com
www.redhat.com is an alias for ds-www.redhat.com.edgekey.net.
ds-www.redhat.com.edgekey.net is an alias for ds-www.redhat.com.edgekey.net.globalredir.akadns.net.
ds-www.redhat.com.edgekey.net.globalredir.akadns.net is an alias for e3396.dscx.akamaiedge.net.
e3396.dscx.akamaiedge.net has address 104.73.38.122
e3396.dscx.akamaiedge.net has IPv6 address 2a02:26f0:fe00:190::d44
e3396.dscx.akamaiedge.net has IPv6 address 2a02:26f0:fe00:1a5::d44
> [root@gitlab-runner-1 ~]# cat /etc/resolv.conf
# Generated by NetworkManager
search cluster-qe.lab.eng.brq.redhat.com
nameserver 10.37.166.1
> [root@gitlab-runner-1 ~]# docker run -ti --rm --hostname test registry-proxy.engineering.redhat.com/rh-osbs/ubi9:9.0.0beta-476 /bin/bash> [root@test /]# cat /etc/redhat-release
Red Hat Enterprise Linux release 9.0 Beta (Plow)
>[root@test /]# cat /etc/resolv.conf
# Generated by NetworkManager
search cluster-qe.lab.eng.brq.redhat.com
nameserver 10.37.166.1
> [root@test /]# curl http://www.redhat.com
curl: (6) getaddrinfo() thread failed to start
The same behaviour can be observed on physical hardware with all packages upgraded to latest Z-stream.
Package versions:
kernel-3.10.0-957.61.1.el7.x86_64
docker-1.13.1-102.git7f2769b.el7.x86_64
Running ubi8 image instead of ubi9 the container can resolve correctly.
It's certainly be really helpful for glibc if we backported the "return ENOSYS instead of EPERM" bits to our docker/podman as far back as is reasonable though. But OTOH it's exactly the kind of churn that also incurs some risk in the RHEL7 lifecycle now.
(In reply to Colin Walters from comment #5)
> This is just the latest iteration of seccomp rules vs glibc, see e.g.
> https://bugzilla.redhat.com/show_bug.cgi?id=1900021 and
> https://bugzilla.redhat.com/show_bug.cgi?id=1985499
>
> We need to remind our customers of this matrix
> https://access.redhat.com/support/policy/rhel-container-compatibility (which
> should be extended to include RHEL9) and that the general rule is that you
> can run RHEL N on a RHEL N+1 kernel, but not RHEL N+1 on RHEL N kernel. And
> in this case, 7 is much less than 9.
>
> Basically if you want to run RHEL9 or modern userspace in a container, keep
> your host up to date.
I understand that having rhel7.6 as a host is way behind so what would be recommended solution to run rhel9 containers?
We cannot really run rhel9 for production purposes so my expectation would be that rhel8 should be able to run rhel9 containers. Is it?
Michal,
Yes, you can run rhel9 containers on a rhel8 host. There has been some early testing for that. Just a note, you would be running using Podman instead of Docker.
I ran into this issue on Ubuntu 20.04 when trying to run a Fedora rawhide image.
The work around was to use: --security-opt seccomp=unconfined
on the docker command line.
I am also trying to run the image with a Gitlab runner but the OS is Ubuntu 20.04.
(In reply to Scott McCarty from comment #10)
> John, could you highlight which way is which, do you mean you are running an
> Ubuntu container image on a Fedora rawhide host, or vice versa?
Ubuntu 20.04 host and running Fedora as the container. From my understanding this is because of change in Fedora on the version of glibc.