qemu-devel
[Top][All Lists]
Advanced

[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: Tobias Koch
Subject: [Bug 1823790] Re: QEMU mishandling of SO_PEERSEC forces systemd into tight loop
Date: Wed, 29 Jan 2020 06:20:57 -0000

I'm a bit surprised that this bug doesn't get more attention, as it
makes it very hard to run qemu-emulated containers of Bionic hosted on
Bionic. Running such containers is a common way to cross-compile
packages for foreign architectures in the absence of sufficiently
powerful target HW.

The documentation on SO_PEERSEC is indeed sparse, but I do want to
second Fritz in his approach. I don't see a reason, why treating the
payload as incorrect and throwing it back at the application is better
than handling it and saying it is not implemented (which is the case).

Arguably, applications should be fixed to handle the error correctly,
but I'm afraid that is a can of worms. I have encountered the same
problem with systemd, apt and getent. Would the maintainers be open to
an SRU request on QEMU for this?

-- 
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:
  New

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]