LXC 4.0.x and libcgroups for Slackware-current

mbroek · 08-10-2021, 03:00 AM

Quote:

Originally Posted by alex14641

It's not what LC says, but the way he says it: his comments have a belittling/insulting tone.

I have been running a modified rc.elogind to facilitate using LXC 4.x to run unprivileged CentOS/Ubuntu containers ever since elogind was integrated into slackware, with no ill effects: the way the original rc.elogind creates /sys/fs/cgroup/systemd conflicts with what's needed by systemd-based containerized distributions.

I agree on both points. Btw, how did you solve this?

ZhaoLin1457 · 08-10-2021, 05:19 AM

Quote:

Originally Posted by mbroek

I just tested this suggestion, unfortunately it doesn't work. It seems that the original path is checked which isn't a path but a symlink.

Then they talk about named cgroups, but in fact those cgroups aren't that named? I think this could be considered a issue on LXC 4.x

Quote:

Originally Posted by mbroek

Code:

root@seaport:~# lxc-start -F -n stretch
lxc-start: stretch: cgroups/cgfsng.c: __initialize_cgroups: 3249 Not a directory - Failed to open 10/systemd
lxc-start: stretch: cgroups/cgfsng.c: initialize_cgroups: 3381 Not a directory - Failed to initialize cgroups
lxc-start: stretch: cgroups/cgroup.c: cgroup_init: 35 Bad file descriptor - Failed to initialize cgroup driver
lxc-start: stretch: start.c: lxc_init: 872 Failed to initialize cgroup driver
lxc-start: stretch: start.c: __lxc_start: 1987 Failed to initialize container "stretch"
lxc-start: stretch: tools/lxc_start.c: main: 308 The container failed to start
lxc-start: stretch: tools/lxc_start.c: main: 313 Additional information can be obtained by setting the --logfile and --logpriority options
root@seaport:~#

The real question might be: why is that symlink in the elogind package created? Slackware should not need it right?

Regarding this elogind setup probably Mr. Volkerding can give us a proper response.

But, I think that the real question might be: why LXC 4.x wants this particular "systemd" cgroup on the host system? For what?

And looking on the lxc-4.0.10/src/lxc/cgroups/cgfsng.c somewhere just before your first error:

Code:

/**
 * systemd guarantees that the order of co-mounted controllers is stable. On
 * some systems the order of the controllers might be reversed though.
 *
 * For example, this is how the order is mismatched on CentOS 7:
 *
 *      [root@localhost ~]# cat /proc/self/cgroup
 *      11:perf_event:/
 *      10:pids:/
 *      9:freezer:/
 * >>>> 8:cpuacct,cpu:/
 *      7:memory:/
 *      6:blkio:/
 *      5:devices:/
 *      4:hugetlb:/
 * >>>> 3:net_prio,net_cls:/
 *      2:cpuset:/
 *      1:name=systemd:/user.slice/user-0.slice/session-c1.scope
 *
 * whereas the mountpoint:
 *
 *      | |-/sys/fs/cgroup                    tmpfs         tmpfs      ro,nosuid,nodev,noexec,mode=755
 *      | | |-/sys/fs/cgroup/systemd          cgroup        cgroup     rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd
 *      | | |-/sys/fs/cgroup/cpuset           cgroup        cgroup     rw,nosuid,nodev,noexec,relatime,cpuset
 * >>>> | | |-/sys/fs/cgroup/net_cls,net_prio cgroup        cgroup     rw,nosuid,nodev,noexec,relatime,net_prio,net_cls
 *      | | |-/sys/fs/cgroup/hugetlb          cgroup        cgroup     rw,nosuid,nodev,noexec,relatime,hugetlb
 *      | | |-/sys/fs/cgroup/devices          cgroup        cgroup     rw,nosuid,nodev,noexec,relatime,devices
 *      | | |-/sys/fs/cgroup/blkio            cgroup        cgroup     rw,nosuid,nodev,noexec,relatime,blkio
 *      | | |-/sys/fs/cgroup/memory           cgroup        cgroup     rw,nosuid,nodev,noexec,relatime,memory
 * >>>> | | |-/sys/fs/cgroup/cpu,cpuacct      cgroup        cgroup     rw,nosuid,nodev,noexec,relatime,cpuacct,cpu
 *      | | |-/sys/fs/cgroup/freezer          cgroup        cgroup     rw,nosuid,nodev,noexec,relatime,freezer
 *      | | |-/sys/fs/cgroup/pids             cgroup        cgroup     rw,nosuid,nodev,noexec,relatime,pids
 *      | | `-/sys/fs/cgroup/perf_event       cgroup        cgroup     rw,nosuid,nodev,noexec,relatime,perf_event
 *
 * Ensure that we always use the systemd-guaranteed stable order when checking
 * for the mountpoint.
 */

Then, systemd this, systemd that, CentOS this, but I see no notice regarding elogind.

Hence, this is my question: is compatible LXC 4.x with elogind or the systemd on host system is a requirement for its optimal work?

After all, which Slackware program handles those /sys/fs/cgroup/systemd/user.slice/user-$uid/session-n.scope scopes which they mention on pam_cgfs man page?

mbroek · 08-10-2021, 06:07 AM

To clarify some things, this problem is not here since LXC4, LXC2 (and maybe earlier) has the same problem. The problem is caused by the os running in lxc, as soon as a guest uses systemd the systemd cgroup mount is needed and also a unified cgroup2.

A Slackware in a container doesn't need this and will not complain and is happy without.

Maybe the person who introduced the elogind package (alienBob?) in current could explain why /sys/fs/cgroup/systemd is a link and not a directory.

alex14641 · 08-10-2021, 04:15 PM

Quote:

Originally Posted by mbroek

I agree on both points. Btw, how did you solve this?

https://www.linuxquestions.org/quest...3/#post6263755

You shouldn't have to build and install lxc, but you should install lxcfs: without it, uptime in the container will return the host's uptime. With this setup, the network starts automatically.

P.S: the root entries in /etc/subuid and /etc/subgid are not necessary.

mbroek · 08-11-2021, 02:25 AM

Quote:

Originally Posted by alex14641

https://www.linuxquestions.org/quest...3/#post6263755

You shouldn't have to build and install lxc, but you should install lxcfs: without it, uptime in the container will return the host's uptime. With this setup, the network starts automatically.

P.S: the root entries in /etc/subuid and /etc/subgid are not necessary.

Thanks. While I don't really need to run the containers as a user, there may be some other advantages in my case.

alex14641 · 08-11-2021, 04:52 PM

Quote:

Originally Posted by alex14641

https://www.linuxquestions.org/quest...3/#post6263755

You shouldn't have to build and install lxc, but you should install lxcfs: without it, uptime in the container will return the host's uptime. With this setup, the network starts automatically.

P.S: the root entries in /etc/subuid and /etc/subgid are not necessary.

These scripts facilitate creating/managing unprivileged containers. I would appreciate feedback from anyone using these scripts and patch.

oily · 08-12-2021, 03:38 AM

Quote:

Originally Posted by alex14641

These scripts facilitate creating/managing unprivileged containers. I would appreciate feedback from anyone using these scripts and patch.

Thanks for these scripts, I'll give them a try. I've been meaning to for a few evenings but domestic matters have interfered somewhat, including cleaning rotten potatoes off the carpet last night.

oily · 08-22-2021, 05:24 PM

Quote:

Originally Posted by alex14641

These scripts facilitate creating/managing unprivileged containers. I would appreciate feedback from anyone using these scripts and patch.

I've had a bit of a go with this and it seems to work for me. A few comments:

- Line 4 in lxc-env.sh should be commented out

- I needed to create the directory /var/lib/lxcfs for lxc-init.sh to work
- With the default permissions on the unprivileged user's .local/share directory, containers were unable to start. For the sake of only opening access to the minimum necessary extent I used ACL to allow the container's mapped root account access with

Code:

setfacl -m 131072:rwx .local/share

No other comments beyond that, thanks for your work on this.

alex14641 · 08-22-2021, 05:35 PM

Quote:

Originally Posted by oily

No other comments beyond that, thanks for your work on this.

Thanks for the feedback. With the patch to rc.elogind, are you having any issues?

oily · 08-22-2021, 07:08 PM

Quote:

Originally Posted by alex14641

Thanks for the feedback. With the patch to rc.elogind, are you having any issues?

I certainly haven't noticed anything unexpected in how my system is behaving. If anyone more familiar with how elogind works could try this as well and comment that would be very helpful.

walecha · 08-31-2021, 03:37 AM

Quote:

Originally Posted by mbroek

To clarify some things, this problem is not here since LXC4, LXC2 (and maybe earlier) has the same problem. The problem is caused by the os running in lxc, as soon as a guest uses systemd the systemd cgroup mount is needed and also a unified cgroup2.

A Slackware in a container doesn't need this and will not complain and is happy without.

Maybe the person who introduced the elogind package (alienBob?) in current could explain why /sys/fs/cgroup/systemd is a link and not a directory.

I think it's because the majority of desktop-related program (gnome3/kde5) + wayland is looking for /sys/fs/cgroup/systemd. Symlinked /sys/fs/cgroup/systemd to /sys/fs/cgroup/elogind was sufficient to run gdm or sddm and tracking user session from login to logout.

https://gitlab.com/w41l/kde-elogind/...ind/rc.elogind

I remember I have mention somewhere in the comment section of AlienBob blog, that this kind of hack will make some difficulty for systemd-OS in LXC inside elogind cgroup. I know because I had one back then.

Edit: But my guess is if Slackware change cgroup v1 (legacy) to unified or hybrid, running systemd-OS in LXC v4 in Slackware shouldn't be a problem because the cgroup entries of host and guest will be separated completely as explained in here https://wiki.gentoo.org/wiki/LXD#Run...n_OpenRC_hosts.