[Top][All Lists]

[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: Thu, 20 Feb 2020 06:56:35 -0000

Laurent's patch worked for me as well.

I grabbed the source for the Debian 10 qemu-user-static package,
qemu_3.1+dfsg-8+deb10u3, applied the patch and re-built the qemu-arm-
static binary. Copying the new binary into a Docker image based on
arm32v7/debian:10-slim allowed /sbin/init to bring up the container with
a responsive systemctl command.

Prior to the patch, systemd did not start any services inside the
container and systemctl would hang when executed directly.


You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

  QEMU mishandling of SO_PEERSEC forces systemd into tight loop

Status in QEMU:

Bug description:
  While building Debian images for embedded ARM target systems I
  detected that QEMU seems to force newer systemd daemons into a tight

  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 

  To easily reproduce the issue I have created the following repository:

  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:

To manage notifications about this bug go to:

reply via email to

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