Bug 1992708

Summary: RHEL 9 Beta container fails to resolve with "getaddrinfo() thread failed to start" when run using systemd-nspawn on RHEL 8.4
Product: Red Hat Enterprise Linux 8 Reporter: Javier Peña <jpena>
Component: systemdAssignee: Jacek Migacz <jmigacz>
Status: CLOSED DUPLICATE QA Contact: Frantisek Sumsal <fsumsal>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.4CC: anoopcs, chorn, dtardon, jmigacz, jpichon, markus.falb, praiskup, systemd-maint-list, xavier
Target Milestone: beta   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-04-21 12:29:44 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
strace log none

Description Javier Peña 2021-08-11 15:39:39 UTC 
Description of problem:

When a RHEL 9 container is run using systemd-nspawn on a RHEL 8.4 host, it fails to resolve external addresses. This has been seen when trying to build packages with mock and a RHEL 9 buildroot, but I can reproduce it outside of it.

Version-Release number of selected component (if applicable):

- systemd-container-239-45.el8_4.3.x86_64
- systemd-239-45.el8_4.3.x86_64

How reproducible:

Always

Steps to Reproduce:

$ mkdir nspawntest
$ podman pull registry-proxy.engineering.redhat.com/rh-osbs/ubi9:9.0.0beta-476
$ podman create --name test registry-proxy.engineering.redhat.com/rh-osbs/ubi9:9.0.0beta-476
$ podman export test | tar -x -C nspawntest
$ podman rm test
$ sudo systemd-nspawn --machine nspawntest --directory nspawntest /bin/bash

<inside container>
[root@nspawntest /]# curl http://www.redhat.com
curl: (6) getaddrinfo() thread failed to start

Actual results:
It fails to resolve

Expected results:
curl works as usual, and can resolve the hostname

Additional info:
This looks very similar to https://bugzilla.redhat.com/show_bug.cgi?id=1990469, but in this case it is happening on a RHEL 8.4 system with systemd-nspawn.

I have also seen the issue happen on a CentOS Stream 8 host, when trying to build a package using mock and a CentOS Stream 9 buildroot.
Comment 1 David Tardon 2021-08-27 11:01:54 UTC 
(In reply to Javier Peña from comment #0)
> Additional info:
> This looks very similar to
> https://bugzilla.redhat.com/show_bug.cgi?id=1990469, but in this case it is
> happening on a RHEL 8.4 system with systemd-nspawn.

However, the reason is almost certainly the same--seccomp rules. If it is really so can be easily checked--using systemd-239-48.el8 or newer--by running nspawn with SYSTEMD_SECCOMP=0 exported.
Comment 2 Javier Peña 2021-08-27 11:33:50 UTC 
(In reply to David Tardon from comment #1)
> (In reply to Javier Peña from comment #0)
> > Additional info:
> > This looks very similar to
> > https://bugzilla.redhat.com/show_bug.cgi?id=1990469, but in this case it is
> > happening on a RHEL 8.4 system with systemd-nspawn.
> 
> However, the reason is almost certainly the same--seccomp rules. If it is
> really so can be easily checked--using systemd-239-48.el8 or newer--by
> running nspawn with SYSTEMD_SECCOMP=0 exported.

I have tested it with systemd-239-50.el8, and it works as you mentioned when SYSTEMD_SECCOMP=0 is set.
Comment 3 Pavel Raiskup 2021-11-26 08:59:33 UTC 
Created attachment 1843681 [details]
strace log

Hello, reproduced with:

# rpm -q kernel systemd selinux-policy-targeted container-selinux
kernel-4.18.0-350.el8.x86_64
systemd-239-51.el8.x86_64
selinux-policy-targeted-3.14.3-83.el8.noarch
container-selinux-2.170.0-1.module+el8.6.0+12855+99934f16.noarch


# dnf --installroot /var/tmp/f35-root --disablerepo='*' --enablerepo f35 --repofrompath=f35,https://kojipkgs.fedoraproject.org/repos/f35-build/latest/x86_64/ --nogpgcheck install strace


# /usr/bin/systemd-nspawn -q  -D /var/tmp/f35-root -a --capability=cap_ipc_lock --bind=/etc/resolv.conf:/etc/resolv.conf --setenv=SHELL=/bin/bash --setenv=LC_MESSAGES=C.UTF-8 --resolv-conf=off bash

// in container

bash-5.1# rpm -q glibc curl
glibc-2.34-8.fc35.x86_64
curl-7.79.1-1.fc35.x86_64

bash-5.1# strace curl https://fedoraproject.org
(log attached)
Comment 4 Pavel Raiskup 2021-11-26 09:00:52 UTC 
This breaks mock build with --isolation=nspawn on EL5:
https://github.com/rpm-software-management/mock/issues/811
Comment 5 Anoop C S 2021-11-26 09:52:33 UTC 
*** Bug 2007758 has been marked as a duplicate of this bug. ***
Comment 6 Pavel Raiskup 2021-11-26 11:45:43 UTC 
> This breaks mock build with --isolation=nspawn on EL5:

Meh, what a typo ... I meant that it breaks mock on EL8.
Comment 7 Pavel Raiskup 2021-12-16 15:00:49 UTC 
Is this going to be ever considered for a fix in EL8?  Or is this a clear
WONTFIX/NOTABUG?  Just thinking about what we should do in Mock (see
the issue link mentioned before).
Comment 8 Christian Horn 2022-02-18 22:23:36 UTC 
Is bz2026147 related?
Fedora containers not running properly out of the box on non-Fedora hypervisors is not good..
Comment 9 David Tardon 2022-03-01 07:16:41 UTC 
(In reply to Pavel Raiskup from comment #7)
> Is this going to be ever considered for a fix in EL8?  Or is this a clear
> WONTFIX/NOTABUG?  Just thinking about what we should do in Mock (see
> the issue link mentioned before).

You can export SYSTEMD_SECCOMP=0 as suggested above.
Comment 10 Pavel Raiskup 2022-03-01 14:59:31 UTC 
Yes, done in mock-2.16-1.
Comment 11 David Tardon 2022-04-21 12:29:44 UTC 

*** This bug has been marked as a duplicate of bug 2040247 ***