yahoo-eng-team team mailing list archive

[Dan Streetman <1905493@xxxxxxxxxxxxxxxxxx>]

The systemd-logind problem is due to dbus defaulting to apparmor mode
'enabled', but apparmor can't do much of anything inside a container so
it fails to start, and dbus can't contact it.

In the 2nd level container, create a file like '/etc/dbus-1/system.d/no-
apparmor.conf' with content:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE busconfig PUBLIC
 "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd";>
<busconfig>
  <apparmor mode="disabled"/>
</busconfig>


Then restart the 2nd level container and recheck systemd-logind which should now work

Of course, fixing dbus should be a bit smarter about only disabling its
use of apparmor if it's inside a container.


However, cloud-init status --wait still hangs after systemd-logind starts up, so that wasn't the original problem (or at least wasn't the only problem)

** Also affects: dbus (Ubuntu)
   Importance: Undecided
       Status: New

** Changed in: systemd (Ubuntu)
       Status: New => Invalid

** Changed in: cloud-init
       Status: Invalid => New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1905493

Title:
  cloud-init status --wait hangs indefinitely in a nested lxd container

Status in cloud-init:
  New
Status in dbus package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Invalid

Bug description:
  When booting a nested lxd container inside another lxd container (just
  a normal container, not a VM) (i.e. just L2), using cloud-init -status
  --wait, the "." is just printed off infinitely and never returns.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1905493/+subscriptions