[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug 1823790] Re: QEMU mishandling of SO_PEERSEC forces systemd into tig
From: |
Charlie Sharpsteen |
Subject: |
[Bug 1823790] Re: QEMU mishandling of SO_PEERSEC forces systemd into tight loop |
Date: |
Sun, 20 Sep 2020 18:06:15 -0000 |
In my case the issue with using Ubuntu 20.04 as a container host appears
to have come down to the use of the F, or "fix binary", flag by
binfmnt_misc:
# cat /proc/sys/fs/binfmt_misc/qemu-aarch64
enabled
interpreter /usr/bin/qemu-aarch64-static
flags: OCF
offset 0
magic 7f454c460201010000000000000000000200b700
mask ffffffffffffff00fffffffffffffffffeffffff
This appears to be new in Ubuntu 20.04 relative to 18.04 and results in
the qemu-user-static binaries being loaded and locked into memory _when
the package is installed_.
Therefore, what I observed as a regression of the issue was actually
just the packaged binaries now taking precedence over patched versions
that I had built and copied into place.
Ubuntu 20.04 ships QEMU 4.2. Using the QEMU 5.1 packages from Debian
Bullseye allows SystemD to run in a foreign architecture container
without spinning in a loop:
https://packages.debian.org/bullseye/qemu-user-static
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1823790
Title:
QEMU mishandling of SO_PEERSEC forces systemd into tight loop
Status in QEMU:
Fix Released
Bug description:
While building Debian images for embedded ARM target systems I
detected that QEMU seems to force newer systemd daemons into a tight
loop.
My setup is the following:
Host machine: Ubuntu 18.04, amd64
LXD container: Debian Buster, arm64, systemd 241
QEMU: qemu-aarch64-static, 4.0.0-rc2 (custom build) and 3.1.0 (Debian
1:3.1+dfsg-7)
To easily reproduce the issue I have created the following repository:
https://github.com/lueschem/edi-qemu
The call where systemd gets looping is the following:
2837 getsockopt(3,1,31,274891889456,274887218756,274888927920) = -1 errno=34
(Numerical result out of range)
Furthermore I also verified that the issue is not related to LXD.
The same behavior can be reproduced using systemd-nspawn.
This issue reported against systemd seems to be related:
https://github.com/systemd/systemd/issues/11557
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1823790/+subscriptions
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Bug 1823790] Re: QEMU mishandling of SO_PEERSEC forces systemd into tight loop,
Charlie Sharpsteen <=