Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#70329 - [systemd][lxc] unprivileged container can no longer start with systemd 248

Attached to Project: Arch Linux
Opened by Holger RĂ¼diger (manti7) - Wednesday, 07 April 2021, 09:16 GMT
Last edited by Andreas Radke (AndyRTR) - Wednesday, 21 April 2021, 06:22 GMT
Task Type Bug Report
Category Packages: Extra
Status Assigned
Assigned To Christian Hesse (eworm)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 2
Private No

Details

Description:

With systemd 248 CGroup V2 (systemd.unified_cgroup_hierarchy=1) is activated by default and pam_cgfs.so does not work anymore.

The pam_cgfs.so allows an unprivileged user to write to CGroup V1, but not to CGroup V2. This means that the instructions in the wiki are no longer works [1].

The following workarounds can be found on the internet:


#1 run systemd with cgroup v1

/etc/default/grub
---
GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=0"
---

$ grub-mkconfig -o /boot/grub/grub.cfg


#2 lxc container with systemd delegate [2]

$ systemctl edit user@1000.service

---
[Service]
delegate=yes
---

$ systemd-run --user --scope lxc-start -n xxxxx


I don't like either workaround. LXC as an application would take care of systemd with the user and scope itself.



Additional info:

systemd-248-3-x86_64
lxc-1:4.0.6-1
arch-install-scripts-23-2


The error message:

$ lxc-create -n xxxxx -t download -- --dist alpine --release edge --arch amd64
$ lxc-start -F -n xxxxx

---
lxc-start: xxxxx: cgroups/cgfsng.c: __cgfsng_delegate_controllers: 3085 Device or resource busy - Could not enable "+memory +pids" controllers in the unified cgroup "/sys/fs/cgroup/user.slice/user-1000.slice/session-1.scope/cgroup.subtree_control"
lxc-start: xxxxx: start.c: __lxc_start: 1972 Failed to delegate controllers to monitor cgroup
lxc-start: xxxxx: tools/lxc_start.c: main: 308 The container failed to start
lxc-start: xxxxx: tools/lxc_start.c: main: 313 Additional information can be obtained by setting the --logfile and --logpriority options
---


Steps to reproduce [1]:


$ pacman -S lxc arch-install-scripts


/etc/pam.d/system-login
---
session optional pam_cgfs.so -c all
---

/etc/subuid
---
1000:100000:65536
---

/etc/subgid
---
1000:100000:65536
---

$ mkdir ~/.config/lxc
$ mkdir ~/.local/share/lxc

~/.config/lxc/default.conf
---
lxc.idmap = u 0 100000 1000
lxc.idmap = g 0 100000 1000
lxc.idmap = u 1000 1000 1
lxc.idmap = g 1000 1000 1
lxc.idmap = u 1001 101001 64535
lxc.idmap = g 1001 101001 64535
---


$ lxc-create -n xxxxx -t download -- --dist alpine --release edge --arch amd64
$ lxc-start -F -n xxxxx



Arch Linux Wiki Links:

[1] https://wiki.archlinux.org/index.php/Linux_Containers
[2] https://wiki.archlinux.org/index.php/Cgroups
This task depends upon

Comment by Christian Hesse (eworm) - Wednesday, 07 April 2021, 10:43 GMT
What do you think should happen now?
Comment by Morten Linderud (Foxboron) - Wednesday, 07 April 2021, 11:05 GMT
I don't think this is a packaging bug. This is a documentation issue in the wiki. pam_cgfs.so doesn't support cgroup v2 and the wiki needs to reflect that, but that isn't grounds for a bugreport?
Comment by Holger RĂ¼diger (manti7) - Tuesday, 13 April 2021, 11:29 GMT
I may have found a way to solve the problem. It may be that something needs to be changed in the package or in the dependencies. The wiki must be changed in any case. I will get back to you as soon as possible.
Comment by Justin (jjb2021) - Monday, 10 May 2021, 14:35 GMT
Might be worth adding a link to this issue I raised in the LXC forum ... I don't know if this is a completely different issue, or related to this one.
https://discuss.linuxcontainers.org/t/container-wont-start-lxc-rootfs-init-bad-file-descriptor/11024?u=jjb2018
Comment by Morten Linderud (Foxboron) - Monday, 10 May 2021, 16:08 GMT
Completely different issue most likely.

Loading...