group.of.nepali.translators team mailing list archive

[Dan Streetman <1962332@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

[impact]

now that jammy has moved to using unified cgroup2, containers started on
jammy must also use unified cgroup2 (since the cgroup subsystems can
only be mounted as v1 or v2 throughout the entire system, including
inside containers).

However, the systemd in xenial does not include support for cgroup2, and
doesn't recognize its magic (added in upstream commit 099619957a0), so
it fails to start completely.

[test case]

create a jammy system, that has unified cgroup2 mounted. Then:

$ lxc launch ubuntu:xenial test-x
...
$ lxc shell test-x

(inside xenial container):
$ mv /sbin/init /sbin/init.old
$ cat > /sbin/init <<EOF
#!/bin/bash
sleep 2
exec /lib/systemd/systemd --log-level=debug --log-target=console
EOF
$ chmod 755 /sbin/init
$ exit

(back in jammy host system):
$ lxc stop test-x -f
$ lxc start --console test-x
To detach from the console, press: <ctrl>+a q
Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted
[!!!!!!] Failed to mount API filesystems, freezing.
Freezing execution.

[regression potential]

any regression would likely break xenial containers from starting at
all, or cause cgroup-related problems with systemd starting and/or
managing services.

[scope]

this is needed only for xenial. However, as xenial is out of standard
support, this would need to be an exception.

this is fixed upstream with commit 099619957a0 (and possibly others -
needs closer investigation and testing) which is first included in v230,
so this is fixed already in f and later.

this is not needed - by default - for trusty because upstart is used
there; however, I think it's possible to change trusty over to use
systemd instead of upstart. But since trusty is out of standard support,
and it doesn't fail by default, it doesn't seem like it should be fixed.

[other info]

An alternative appears to be to change the host system back to using the
'hybrid' cgroup, however that obviously is awful and would remove the
benefits of cgroup v2 from the host system, and force all containers on
the host system to also use the 'hybrid' cgroup.

** Affects: systemd (Ubuntu)
     Importance: Undecided
         Status: Fix Released

** Affects: systemd (Ubuntu Xenial)
     Importance: Undecided
         Status: New

** Also affects: systemd (Ubuntu Xenial)
   Importance: Undecided
       Status: New

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

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1962332

Title:
  xenial systemd fails to start if cgroup2 is mounted

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  New

Bug description:
  [impact]

  now that jammy has moved to using unified cgroup2, containers started
  on jammy must also use unified cgroup2 (since the cgroup subsystems
  can only be mounted as v1 or v2 throughout the entire system,
  including inside containers).

  However, the systemd in xenial does not include support for cgroup2,
  and doesn't recognize its magic (added in upstream commit
  099619957a0), so it fails to start completely.

  [test case]

  create a jammy system, that has unified cgroup2 mounted. Then:

  $ lxc launch ubuntu:xenial test-x
  ...
  $ lxc shell test-x

  (inside xenial container):
  $ mv /sbin/init /sbin/init.old
  $ cat > /sbin/init <<EOF
  #!/bin/bash
  sleep 2
  exec /lib/systemd/systemd --log-level=debug --log-target=console
  EOF
  $ chmod 755 /sbin/init
  $ exit

  (back in jammy host system):
  $ lxc stop test-x -f
  $ lxc start --console test-x
  To detach from the console, press: <ctrl>+a q
  Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted
  [!!!!!!] Failed to mount API filesystems, freezing.
  Freezing execution.

  [regression potential]

  any regression would likely break xenial containers from starting at
  all, or cause cgroup-related problems with systemd starting and/or
  managing services.

  [scope]

  this is needed only for xenial. However, as xenial is out of standard
  support, this would need to be an exception.

  this is fixed upstream with commit 099619957a0 (and possibly others -
  needs closer investigation and testing) which is first included in
  v230, so this is fixed already in f and later.

  this is not needed - by default - for trusty because upstart is used
  there; however, I think it's possible to change trusty over to use
  systemd instead of upstart. But since trusty is out of standard
  support, and it doesn't fail by default, it doesn't seem like it
  should be fixed.

  [other info]

  An alternative appears to be to change the host system back to using
  the 'hybrid' cgroup, however that obviously is awful and would remove
  the benefits of cgroup v2 from the host system, and force all
  containers on the host system to also use the 'hybrid' cgroup.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+subscriptions