[Bug 1823790] Re: QEMU mishandling of SO_PEERSEC forces systemd into tight loop

[Christian Ehrhardt ]

Bisect worked and once you find it it seems obvious that this is exactly
our case:

commit 65b261a63a48fbb3b11193361d4ea0c38a3c3dfd
Author: Laurent Vivier <laurent@vivier.eu>
Date:   Thu Jul 9 09:23:32 2020 +0200

    linux-user: add netlink RTM_SETLINK command
    
    This command is needed to be able to boot systemd in a container.
    
      $ sudo systemd-nspawn -D /chroot/armhf/sid/ -b
      Spawning container sid on /chroot/armhf/sid.
      Press ^] three times within 1s to kill container.
      systemd 245.6-2 running in system mode.
      Detected virtualization systemd-nspawn.
      Detected architecture arm.
    
      Welcome to Debian GNU/Linux bullseye/sid!
    
      Set hostname to <virt-arm>.
      Failed to enqueue loopback interface start request: Operation not 
supported
      Caught <SEGV>, dumped core as pid 3.
      Exiting PID 1...
      Container sid failed with error code 255.
    
    Signed-off-by: Laurent Vivier <laurent@vivier.eu>
    Message-Id: <20200709072332.890440-2-laurent@vivier.eu>

 linux-user/fd-trans.c | 1 +
 1 file changed, 1 insertion(+)

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