Translation(s):


This page explains troubleshooting of using LXC (Linux Container) on Debian hosts booted with systemd.unified_cgroup_hierarchy=1 in kernel command-line. The content of this page is verified with lxc (1:3.1.0+really3.0.3-8) on Debian Buster and lxc (1:3.1.0+really3.0.4-2, 1:4.0.2-1~1 and, 1:4.0.6-1~1) on Debian Bullseye. Discussion on this page

Unified CGroup Hierarchy is coming

Systemd has three kinds of CGroup hierarchies, namely legacy, hybrid and unified cgroup hierarchies. The unified hierarchy consists only of CGroup version 2. Traditionally Debian has used the hybrid hierarchy, but as discussed in 943981 the unified hierarchy will likely become the new default hierarchy. We need some adjustments to LXC container config files on hosts booted in the unified CGroup hierarchy, which are explained here. Advantages of the unified hierarchy are explained at The current adoption status of cgroup v2 in containers.

LXC containers started by root

Removing access control by CGroup V1 device controllers

The unified CGroup hierarchy does not have CGroup V1 device controllers. LXC container config files often have access controls of device files by using CGroup V1 device controllers, by using lxc.cgroup.devices.allow = and lxc.cgroup.devices.deny =. To start an LXC container, we have to remove those access control settings by adding

lxc.cgroup.devices.allow =
lxc.cgroup.devices.deny =

to the end of a container config file, e.g. /var/lib/lxc/container/config. The above change becomes unnecessary from version 4.0.2-1~1.

Start container's systemd in the unified cgroup hierarchy

Most of Linux distros use systemd in the hybrid hierarchy. If container's systemd tries to start in the hybrid hierarchy in an LXC container, it fails to start. To avoid such a failure, we have to add

lxc.init.cmd = /sbin/init systemd.unified_cgroup_hierarchy=1

to a container config file. lxc.init.cmd is necessary only when container's /sbin/init is systemd with the hybrid hierarchy.

When LXC version is 4.0.0 or later, alternatively we can also use

lxc.mount.auto = cgroup:rw:force

By the above line, LXC lets systemd in a container choose the same CGroup hierarchy in a container as the host.

LXC containers started by non-root

Assume that preparation of unprivileged containers has been done. LXC needs a CGroup directory that can be manipulated by LXC, which was traditionally prepared by libpam-cgfs. libpam-cgfs no longer works and becomes unnecessary in the unified hierarchy as 946170.

When lxc-start or lxc-execute is run for lxc (1:4.0.6-1), we can use them, for example, as

systemd-run --user --scope -p "Delegate=yes" lxc-start -n container-name

Previous versions of LXC required as

systemd-run --user --scope -p "Delegate=yes" lxc-start -F -n container-name

otherwise we get error message reported at https://github.com/lxc/lxc/issues/3221. The above call does not work reliably if you want to start the container in the background. You cannot simply omit the -F parameter. Start the container in the background with

systemd-run --user -r -p "Delegate=yes" lxc-start -F -n container-name

See: https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1716279.html

Known Debian problems with Debian package 4.0.2-1~1

Known Debian problems of LXC on host Linux with systemd.unified_cgroup_hierarchy=1