search

facebookincubator / below

A time traveling resource monitor for modern Linux systems
Apache License 2.0
1.09k stars 61 forks source link

below 0.3.0 records an unclean exit (crash) #8122

Open kakra opened 3 years ago

kakra commented 3 years ago

This happens when I'm emerging packages in Gentoo:

# ~ $ below
# ~ $ echo $?
1
# ~ $ below
Nov 04 12:05:08.863 ERRO
----------------- Detected unclean exit ---------------------
Error Message: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }: "portage/net-fs:samba-4.14.9.ccy1d170/io.stat": Permission denied (os error 13)
-------------------------------------------------------------

# ~ $ journalctl -et below --no-hostname
Nov 04 10:45:33 below[2296112]: Nov 04 10:45:33.016 DEBG Starting up!
Nov 04 10:45:38 below[2296112]: Nov 04 10:45:38.015 ERRO System error, errno: 1
Nov 04 10:45:43 below[2296112]: Nov 04 10:45:43.016 WARN bpf error channel disconnected
Nov 04 11:37:13 below[2296112]: Nov 04 11:37:13.202 ERRO panic 'cmdline receiver hung up: SendError { .. }': below/procfs/src/lib.rs:630
Nov 04 11:37:13 below[2296112]: Backtrace is not available.
Nov 04 11:37:18 below[2296112]: Nov 04 11:37:18.175 ERRO panic 'cmdline receiver hung up: SendError { .. }': below/procfs/src/lib.rs:630
Nov 04 11:37:18 below[2296112]: Backtrace is not available.
Nov 04 11:49:28 below[2296112]: Nov 04 11:49:28.238 ERRO panic 'cmdline receiver hung up: SendError { .. }': below/procfs/src/lib.rs:630
Nov 04 11:49:28 below[2296112]: Backtrace is not available.
Nov 04 11:55:48 below[2296112]: Nov 04 11:55:48.197 ERRO panic 'cmdline receiver hung up: SendError { .. }': below/procfs/src/lib.rs:630
Nov 04 11:55:48 below[2296112]: Backtrace is not available.
Nov 04 12:03:23 below[2296112]: Nov 04 12:03:23.230 ERRO panic 'cmdline receiver hung up: SendError { .. }': below/procfs/src/lib.rs:630
Nov 04 12:03:23 below[2296112]: Backtrace is not available.

sys-fs-cgroup.tree.txt

hodgesds commented 3 years ago

What happens when you start with below --debug?

hodgesds commented 3 years ago

I think this might be similar to what I'm seeing as well:

below --debug
libbpf: loading object exitstat_bpf from buffer
libbpf: elf: section(3) tracepoint/sched/sched_process_exit, size 1648, link 0, flags 6, type=1
libbpf: sec tracepoint/sched/sched_process_exit: found program tracepoint__sched__sched_process_exit at insn offset 0 (0 bytes), code size 206 insns (1648 bytes)
libbpf: elf: section(4) .reltracepoint/sched/sched_process_exit, size 16, link 22, flags 0, type=9
libbpf: elf: section(5) .maps, size 24, link 0, flags 3, type=1
libbpf: elf: section(6) license, size 4, link 0, flags 3, type=1
libbpf: license of exitstat_bpf is GPL
libbpf: elf: section(13) .BTF, size 32092, link 0, flags 0, type=1
libbpf: elf: section(15) .BTF.ext, size 1692, link 0, flags 0, type=1
libbpf: elf: section(22) .symtab, size 312, link 1, flags 0, type=2
libbpf: looking for externs among 13 symbols...
libbpf: collected 0 externs total
libbpf: map events: at sec_idx 5, offset 0.
libbpf: map events: found type = 4.
libbpf: map events: found key_size = 4.
libbpf: map events: found value_size = 4.
libbpf: sec .reltracepoint/sched/sched_process_exit: collecting relocation for section(3) tracepoint/sched/sched_process_exit
libbpf: sec .reltracepoint/sched/sched_process_exit: relo #0: insn #198 against events
libbpf: prog tracepoint__sched__sched_process_exit: found map 0 (events, sec 5, off 0) for insn #198
Nov 10 22:35:30.572 ERRO
----------------- Detected unclean exit ---------------------
Error Message: Invalid file format: "/proc/1/cgroup"
-------------------------------------------------------------

I backported a few patches and have a PR (22894) in the Gentoo repository, which should fix this.

kakra commented 3 years ago

I'm using the current Gentoo version 0.4.1 but the problem persists: While portage with cgroup support is running, I can no longer run below with user permission, only running as root works. The problem is that below cannot read the contents of the portage cgroup.

This is only a problem during initialization of below. If it is already running, it seems to just ignore that problem, i.e. it does not crash.

hodgesds commented 3 years ago

Can you add the output of the following commands? It should be similar to this:

$ grep ^rc_cgroup /etc/rc.conf
rc_cgroup_mode="unified"
rc_cgroup_controllers="cpu memory io writeback pids cpuset device freezer perf_event"
rc_cgroup_cleanup="YES"

$ mount | grep cgroup
none on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)

$ ls -lah /sys/fs/cgroup/
total 0
dr-xr-xr-x  8 root root 0 Nov 22 14:44 .
drwxr-xr-x 13 root root 0 Nov 22 14:44 ..
drwxr-xr-x  2 root root 0 Nov 22 14:44 1
-r--r--r--  1 root root 0 Nov 22 14:44 cgroup.controllers
-rw-r--r--  1 root root 0 Nov 22 14:44 cgroup.max.depth
-rw-r--r--  1 root root 0 Nov 22 14:44 cgroup.max.descendants
-rw-r--r--  1 root root 0 Nov 22 14:44 cgroup.procs
-r--r--r--  1 root root 0 Nov 22 14:44 cgroup.stat
-rw-r--r--  1 root root 0 Nov 22 14:44 cgroup.subtree_control
-rw-r--r--  1 root root 0 Nov 22 14:44 cgroup.threads
-rw-r--r--  1 root root 0 Nov 22 14:44 cpu.pressure
-r--r--r--  1 root root 0 Nov 22 14:44 cpuset.cpus.effective
-r--r--r--  1 root root 0 Nov 22 14:44 cpuset.mems.effective
-r--r--r--  1 root root 0 Nov 22 14:44 cpu.stat
drwxr-xr-x  2 root root 0 Nov 22 14:44 dbus
drwxr-xr-x  2 root root 0 Nov 22 14:44 elogind
-rw-r--r--  1 root root 0 Nov 22 14:44 io.cost.model
-rw-r--r--  1 root root 0 Nov 22 14:44 io.cost.qos
-rw-r--r--  1 root root 0 Nov 22 14:44 io.pressure
-r--r--r--  1 root root 0 Nov 22 14:44 io.stat
-r--r--r--  1 root root 0 Nov 22 14:44 memory.numa_stat
-rw-r--r--  1 root root 0 Nov 22 14:44 memory.pressure
-r--r--r--  1 root root 0 Nov 22 14:44 memory.stat
-r--r--r--  1 root root 0 Nov 22 14:44 misc.capacity
drwxr-xr-x  2 root root 0 Nov 22 14:44 NetworkManager
drwxr-xr-x  2 root root 0 Nov 22 14:44 sysklogd
drwxr-xr-x  2 root root 0 Nov 22 14:44 udev

Make sure to check that you are using v2 cgroups by setting rc_cgroup_mode="unified" in the /etc/rc.conf. Using hybrid isn't tested/supported.

hodgesds commented 3 years ago

If this is a Gentoo specific bug please report in the appropriate bug tracker.

kakra commented 3 years ago

I'm using systemd, so there's no rc.conf which does anything useful (and I don't even have one):

# systemctl --version
systemd 249 (249)
+PAM -AUDIT -SELINUX -APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL -ELFUTILS -FIDO2 +IDN2 -IDN +IPTC +KMOD -LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified

Unified cgroups are enabled.

# mount | grep cgroup
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
tmpfs on /sys/fs/cgroup/portage type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/portage/python3.9/cgroup-release-agent,name=portage)

Portage mounts a different cgroup hierarchy while running. It uses it for PID tracking of build processes.

# ls -lah /sys/fs/cgroup/
insgesamt 0
dr-xr-xr-x 14 root root 0 22. Nov 19:13 ./
drwxr-xr-x 11 root root 0 21. Nov 13:21 ../
-r--r--r--  1 root root 0 21. Nov 13:21 cgroup.controllers
-rw-r--r--  1 root root 0 22. Nov 20:58 cgroup.max.depth
-rw-r--r--  1 root root 0 22. Nov 20:58 cgroup.max.descendants
-rw-r--r--  1 root root 0 21. Nov 13:21 cgroup.procs
-r--r--r--  1 root root 0 22. Nov 20:58 cgroup.stat
-rw-r--r--  1 root root 0 22. Nov 20:06 cgroup.subtree_control
-rw-r--r--  1 root root 0 22. Nov 20:58 cgroup.threads
-rw-r--r--  1 root root 0 21. Nov 13:21 cpu.pressure
-r--r--r--  1 root root 0 21. Nov 13:21 cpu.stat
drwxr-xr-x  2 root root 0 21. Nov 13:21 dev-hugepages.mount/
drwxr-xr-x  2 root root 0 21. Nov 13:21 dev-mqueue.mount/
drwxr-xr-x  2 root root 0 21. Nov 13:21 init.scope/
-rw-r--r--  1 root root 0 22. Nov 20:58 io.cost.model
-rw-r--r--  1 root root 0 22. Nov 20:58 io.cost.qos
-rw-r--r--  1 root root 0 21. Nov 13:21 io.pressure
-rw-r--r--  1 root root 0 22. Nov 20:58 io.prio.class
-r--r--r--  1 root root 0 21. Nov 13:24 io.stat
drwxr-xr-x  5 root root 0 21. Nov 13:22 machine.slice/
drwxr-xr-x  5 root root 0 22. Nov 03:50 maintenance.slice/
-rw-r--r--  1 root root 0 21. Nov 13:21 memory.pressure
-r--r--r--  1 root root 0 21. Nov 13:21 memory.stat
dr-xr-xr-x  2 root root 0 22. Nov 19:13 portage/
drwxr-xr-x  2 root root 0 21. Nov 13:21 portage.slice/
drwxr-xr-x  2 root root 0 21. Nov 13:21 sys-fs-fuse-connections.mount/
drwxr-xr-x  2 root root 0 21. Nov 13:21 sys-kernel-config.mount/
drwxr-xr-x  2 root root 0 21. Nov 13:21 sys-kernel-debug.mount/
drwxr-xr-x 68 root root 0 22. Nov 20:55 system.slice/
drwxr-xr-x  3 root root 0 21. Nov 13:22 user.slice/

# ls -lah /sys/fs/cgroup/portage
insgesamt 0
dr-xr-xr-x  2 root root 0 22. Nov 19:13 ./
dr-xr-xr-x 14 root root 0 22. Nov 19:13 ../
-rw-r--r--  1 root root 0 22. Nov 20:03 cgroup.clone_children
-rw-r--r--  1 root root 0 22. Nov 20:03 cgroup.procs
-r--r--r--  1 root root 0 22. Nov 20:03 cgroup.sane_behavior
-rw-r--r--  1 root root 0 22. Nov 19:13 notify_on_release
-rw-r--r--  1 root root 0 22. Nov 19:13 release_agent
-rw-r--r--  1 root root 0 22. Nov 20:03 tasks

While it is running, it will create folders inside that latter directory for each package build:

# tree /sys/fs/cgroup/portage
/sys/fs/cgroup/portage
├── cgroup.clone_children
├── cgroup.procs
├── cgroup.sane_behavior
├── notify_on_release
├── release_agent
├── sys-devel:gcc-11.2.0.i8q8msdx
│   ├── cgroup.clone_children
│   ├── cgroup.procs
│   ├── notify_on_release
│   └── tasks
└── tasks

# ls -al /sys/fs/cgroup/portage/sys-devel:gcc-11.2.0.1qb2887m/
insgesamt 0
drwx------ 2 root root 0 22. Nov 21:01 .
dr-xr-xr-x 3 root root 0 22. Nov 19:13 ..
-rw-r--r-- 1 root root 0 22. Nov 21:01 cgroup.clone_children
-rw-r--r-- 1 root root 0 22. Nov 21:01 cgroup.procs
-rw-r--r-- 1 root root 0 22. Nov 21:01 notify_on_release
-rw-r--r-- 1 root root 0 22. Nov 21:01 tasks
kakra commented 3 years ago

I think this may be caused by Gentoo-specific handling of cgroup in portage but don't think that Gentoo's "below" should carry a Gentoo-specific patch because that usage of cgroups could occur in the wild even for non-Gentoo systems.

OTOH, I'm not sure if the tmpfs should even be mounted to /sys/fs/cgroup/portage - is that really needed for portage cgroup feature to work? Couldn't it just be mounted anywhere, e.g. in /var/tmp/portage/cgroup maybe? In that case, it would actually be worth reporting to b.g.o.

hodgesds commented 2 years ago

FWIW I was finally able to get a systemd based machine for testing and everything seems to work fine (ie non root user) for 0.4.1.

Here are the mounts:

proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
none on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=8131804k,nr_inodes=2032951,mode=755)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
/dev/sda3 on / type btrfs (rw,noatime,ssd,space_cache,subvolid=5,subvol=/)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=1908)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,size=8136880k,nr_inodes=409600)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
ramfs on /run/credentials/systemd-firstboot.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
/dev/sda2 on /boot type ext4 (rw,relatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1627372k,nr_inodes=406843,mode=700,uid=1000,gid=1000)

And the emerge --info:

Portage 3.0.28 (python 3.9.9-final-0, default/linux/amd64/17.1/systemd, gcc-11.2.0, glibc-2.33-r7, 5.16.0-rc2-x86_64 x86_64)
=================================================================
System uname: Linux-5.16.0-rc2-x86_64-x86_64-Intel-R-_Core-TM-_i3-6100U_CPU_@_2.30GHz-with-glibc2.33
KiB Mem:    16273756 total,  15808040 free
KiB Swap:          0 total,         0 free
Timestamp of repository gentoo: Sun, 19 Dec 2021 02:00:01 +0000
Head commit of repository gentoo: 3847abc7f7991bc2cba6b123d011c7aabb84c1eb
sh bash 5.1_p8
ld GNU ld (Gentoo 2.37_p1 p0) 2.37
app-misc/pax-utils:        1.3.3::gentoo
app-shells/bash:           5.1_p8::gentoo
dev-java/java-config:      2.3.1::gentoo
dev-lang/perl:             5.34.0-r3::gentoo
dev-lang/python:           3.9.9::gentoo, 3.10.0_p1::gentoo
dev-lang/rust:             1.56.1::gentoo
dev-util/cmake:            3.21.4::gentoo
dev-util/meson:            0.59.4::gentoo
sys-apps/baselayout:       2.7-r3::gentoo
sys-apps/sandbox:          2.25::gentoo
sys-apps/systemd:          249.6-r1::gentoo
sys-devel/autoconf:        2.71-r1::gentoo
sys-devel/automake:        1.16.4::gentoo
sys-devel/binutils:        2.37_p1::gentoo
sys-devel/binutils-config: 5.4::gentoo
sys-devel/clang:           13.0.0::gentoo
sys-devel/gcc:             11.2.0::gentoo
sys-devel/gcc-config:      2.4::gentoo
sys-devel/libtool:         2.4.6-r6::gentoo
sys-devel/llvm:            13.0.0::gentoo
sys-devel/make:            4.3::gentoo
sys-kernel/linux-headers:  5.10-r1::gentoo (virtual/os-headers)
sys-libs/glibc:            2.33-r7::gentoo
Repositories:

gentoo
    location: /var/db/repos/gentoo
    sync-type: rsync
    sync-uri: rsync://rsync.gentoo.org/gentoo-portage
    priority: -1000
    sync-rsync-extra-opts: 
    sync-rsync-verify-jobs: 1
    sync-rsync-verify-max-age: 24
    sync-rsync-verify-metamanifest: yes

ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="*"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O2 -pipe"
DISTDIR="/var/cache/distfiles"
ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="https://mirror.csclub.uwaterloo.ca/gentoo-distfiles/ rsync://rsync.gtlib.gatech.edu/gentoo https://gentoo.osuosl.org/ https://mirrors.rit.edu/gentoo/"
LANG="C.UTF8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j4"
PKGDIR="/var/cache/binpkgs"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/var/tmp"
SHELL="/bin/bash"
USE="acl alsa amd64 bzip2 cli crypt dri fortran gdbm iconv ipv6 libglvnd libtirpc lm-sensors multilib ncurses networkmanager nls nptl openmp pam pcre pulseaudio readline seccomp split-usr ssl systemd udev unicode xattr zlib" ABI_X86="64" ADA_TARGET="gnat_2020" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx mmxext sse sse2" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="efi-64" INPUT_DEVICES="libinput" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-3 php7-4" POSTGRES_TARGETS="postgres12 postgres13" PYTHON_SINGLE_TARGET="python3_9" PYTHON_TARGETS="python3_9" RUBY_TARGETS="ruby26 ruby27" USERLAND="GNU" VIDEO_CARDS="amdgpu fbdev intel nouveau radeon radeonsi vesa dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq proto steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  ADDR2LINE, AR, ARFLAGS, AS, ASFLAGS, CC, CCLD, CONFIG_SHELL, CPP, CPPFLAGS, CTARGET, CXX, CXXFILT, ELFEDIT, EMERGE_DEFAULT_OPTS, EXTRA_ECONF, F77FLAGS, FC, GCOV, GPROF, INSTALL_MASK, LC_ALL, LD, LEX, LFLAGS, LIBTOOL, LINGUAS, MAKE, MAKEFLAGS, NM, OBJCOPY, OBJDUMP, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, RANLIB, READELF, RUSTFLAGS, SIZE, STRINGS, STRIP, YACC, YFLAGS
kakra commented 2 years ago

Please try running a longer emerge with FEATURES="cgroup", as only this will create the incompatible cgroup during merging packages. While it is running, try starting below, observe the following behavior:

  1. If you start below before emerge, below continues to work just fine.
  2. If you start below while emerge is doing work, below will crash.

I'm not even sure if that needs a systemd machine - it probably doesn't. The simple fact is that programs can create custom cgroups for whatever reason they intent, in this example, portage does it. And below cannot handle that.

brianc118 commented 2 years ago 
# mount | grep cgroup
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
tmpfs on /sys/fs/cgroup/portage type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/portage/python3.9/cgroup-release-agent,name=portage)

I think the problem here is that we have another hierarchy under /sys/fs/cgroup and it's cgroup v1 not cgroup v2?

I don't think there's generally anything in particular preventing users from mounting something under /sys/fs/cgroup. In this case, I wonder if we could make below ignore this nested hierarchies.

kakra commented 2 years ago

I don't think there's generally anything in particular preventing users from mounting something under /sys/fs/cgroup. In this case, I wonder if we could make below ignore this nested hierarchies.

Yes, I think it needs exactly that. Actually, Gentoo's portage just exposes that problem, it's really not Gentoo-specific. Portage uses it to track PIDs of build-processes in its sandbox to properly clean up when finished. Other software might use that cgroup feature for similar things. Actually, portage doesn't seem to do anything beyond with the cgroup, no controllers are enabled - it's just a plain cgroup. It might enable network namespacing and some other sandboxing features but that is probably not a cgroup feature by itself (actually, it can use namespaces even without the cgroup feature).

As an example, we may see such nested cgroups if we run containers that spawn cgroup v1 mounts by themselves.

So below probably needs to detect two situations:

  1. Just a plain mount was mounted within the cgroup v2 hierarchy: that's unlikely but it's totally possible, and below would see no control files at all
  2. A cgroup v1 was mounted inside cgroup v2: below would see control files but in v1 format

To properly still detect errors, below probably needs to explicitly detect the v1 format and ignore that, and not assume that an error in a proposed v2 format is a v1 format, otherwise the v2 error detection is rendered useless.