You are not logged in.

#1 2021-07-26 20:54:40

Nox997
Member
Registered: 2013-03-31
Posts: 15

LXC unprivileged - "Failed to mount cgroup at /sys/fs/cgroup/systemd"

Dear Arch community,

on my arch server, I do have two LXC unprivileged containers running since ~9months without issue.
Those containers still run (one arch linux, one ubuntu focal)

Today, I wanted to create another unprivileged ubuntu focal container with the same user.
Container creation went well, however when starting the container, I run into the following issue:

lxc-start -F -n gandalf-lxcu-openproject
Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted
[!!!!!!] Failed to mount API filesystems.
Exiting PID 1...

The same happens when downloading an arch linux container.

Info on the host:
- arch linux default kernel is used
- system is up-to-date
- btrfs is the underlying file system

Could someone please help me push me into the right direction?

Thank you very much in advance!

Last edited by Nox997 (2021-07-26 20:57:39)

Offline

#2 2021-07-28 22:21:25

Nox997
Member
Registered: 2013-03-31
Posts: 15

Re: LXC unprivileged - "Failed to mount cgroup at /sys/fs/cgroup/systemd"

It turns out I had to read the lxc unprivileged wiki:
https://wiki.archlinux.org/title/Linux_ … d_software

After adding the kernel parameter

systemd.unified_cgroup_hierarchy=0

,
I was able to start the new container.

One question however remains - why did my other two unprivileged LXC containers work flawlessly with cgroupv2?
Is cgroupv1 only necessary for a "first boot" of the container?

Thank you very much in advance!

Last edited by Nox997 (2021-07-28 22:22:37)

Offline

#3 2021-07-30 05:50:13

Nox997
Member
Registered: 2013-03-31
Posts: 15

Re: LXC unprivileged - "Failed to mount cgroup at /sys/fs/cgroup/systemd"

Dear all,

I think I found out why my other containers are working - at least from the coarse direction point of view without understanding the details:
The other LXC unprivileged containers use a user-systemd service for starting.
This service file looks like this:

[Unit]
Description=%i LXC

[Service]
Type=forking
ExecStartPre=/usr/bin/sleep 5
ExecStart=/usr/bin/lxc-start -d -n %i -o /home/lxc_user/%i.log
#PIDFile=/run/lxc-%i.pid
ExecStop=/usr/bin/lxc-stop -n %i
Delegate=True
TasksMax=32768

[Install]
WantedBy=default.target

My guess is that the Delegate=True option does the necessary setup for lxc in terms of cgroups so that the container can start - even with a unified hierarchy.
It would be nice if someone knowledgeable on cgroups, lxc and systemd could comment smile

It seems that the Arch wiki on unprivileged containers is wrong:

  • pam_cgfs.so seems to work still

  • there is no need to use cgroupv1

  • the lxc documentation lists exactly that for unprivileged containers, a start using the delegate option in systemd is mandatory, see link & quote below

Link: https://linuxcontainers.org/lxc/getting-started

LXC Documentation wrote:

Running unprivileged containers as an unprivileged user only works if you delegate a cgroup in advance (the cgroup2 delegation model enforces this restriction, not liblxc). Use the following systemd command to delegate the cgroup:

systemd-run --unit=myshell --user --scope -p "Delegate=yes" lxc-start <container-name>

Last edited by Nox997 (2021-07-30 20:26:37)

Offline

Board footer

Powered by FluxBB