[Bug 1690125] Re: hybrid control goup mode breaks lxc adt tests

[Christian Brauner]

Hey everyone,

Uust as an fyi: I sent a branch https://github.com/lxc/lxc/pull/1713
which is now merged that makes LXC handle the hybrid cgroup case
provided the cgroup v2 mount does not bind any controllers (Which is the
current default). It will be included in the next LXC release.

Thanks!
Christian

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1690125

Title:
  hybrid control goup mode breaks lxc adt tests

Status in lxc:
  New
Status in apparmor package in Ubuntu:
  Incomplete
Status in lxc package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  I will disably hybrid control groups by default for now, but will
  create a ppa with such systemd, for ease of testing.

  
  FAIL: lxc-tests: /usr/bin/lxc-test-apparmor-mount
  ---
  /usr/sbin/deluser: The user `lxcunpriv' does not exist.
  /usr/bin/lxc-test-apparmor-mount: 138: /usr/bin/lxc-test-apparmor-mount: cannot create /sys/fs/cgroup/unified/lxctest/tasks: Permission denied
  Container is not defined
  umount: /sys/kernel/security/apparmor/features/mount: not mounted
  ---

  FAIL: lxc-tests: /usr/bin/lxc-test-unpriv
  ---
  Removing user `lxcunpriv' ...
  Warning: group `lxcunpriv' has no more members.
  Done.
  /usr/bin/lxc-test-unpriv: line 154: /sys/fs/cgroup/unified/lxctest/tasks: Permission denied
  c2 is not running
  c1 is not running
  ---
  FAIL: lxc-tests: /usr/bin/lxc-test-usernic
  ---
  /usr/sbin/deluser: The user `usernic-user' does not exist.
  /usr/bin/lxc-test-usernic: line 111: /sys/fs/cgroup/unified/lxctest/tasks: Permission denied
  FAIL
  ---
  PASS: lxc-tests: /usr/bin/lxc-test-utils
  PASS: python3: API
  Removing 'local diversion of /usr/bin/dirmngr to /usr/bin/dirmngr.orig'

  
  CHANGES WITH 233:

          * The "hybrid" control group mode has been modified to improve
            compatibility with "legacy" cgroups-v1 setups. Specifically, the
            "hybrid" setup of /sys/fs/cgroup is now pretty much identical to
            "legacy" (including /sys/fs/cgroup/systemd as "name=systemd" named
            cgroups-v1 hierarchy), the only externally visible change being that
            the cgroups-v2 hierarchy is also mounted, to
            /sys/fs/cgroup/unified. This should provide a large degree of
            compatibility with "legacy" cgroups-v1, while taking benefit of the
            better management capabilities of cgroups-v2.

          * The default control group setup mode may be selected both a boot-time
            via a set of kernel command line parameters (specifically:
            systemd.unified_cgroup_hierarchy= and
            systemd.legacy_systemd_cgroup_controller=), as well as a compile-time
            default selected on the configure command line
            (--with-default-hierarchy=). The upstream default is "hybrid"
            (i.e. the cgroups-v1 + cgroups-v2 mixture discussed above) now, but
            this will change in a future systemd version to be "unified" (pure
            cgroups-v2 mode). The third option for the compile time option is
            "legacy", to enter pure cgroups-v1 mode. We recommend downstream
            distributions to default to "hybrid" mode for release distributions,
            starting with v233. We recommend "unified" for development
            distributions (specifically: distributions such as Fedora's rawhide)
            as that's where things are headed in the long run. Use "legacy" for
            greatest stability and compatibility only.

          * Note one current limitation of "unified" and "hybrid" control group
            setup modes: the kernel currently does not permit the systemd --user
            instance (i.e. unprivileged code) to migrate processes between two
            disconnected cgroup subtrees, even if both are managed and owned by
            the user. This effectively means "systemd-run --user --scope" doesn't
            work when invoked from outside of any "systemd --user" service or
            scope. Specifically, it is not supported from session scopes. We are
            working on fixing this in a future systemd version. (See #3388 for
            further details about this.)

To manage notifications about this bug go to:
https://bugs.launchpad.net/lxc/+bug/1690125/+subscriptions