cgroup v1 rdma.current about cgroups HOT 6 CLOSED

Wait, you said you're loading and calling stat on the cgroup2 manager, but the path it's trying to open is a cgroup1 path which is odd. The cgroup 2 codepath doesn't error out on the only instance of trying to read the equivalent file in the cgroup:

from cgroups.

oh. i see. this is probably my mistake then. It seems the underlying nodes support unified cgroups but within the container is only supporting legacy? that must have confused me.

I am probably then just doing cgroup1 path wrong? I will debug and close the issue in a bit if im just being stupid. really appreciate the help!!

from cgroups.

No worries, not stupid at all. I'm curious to know the outcome!

from cgroups.

No worries, not stupid at all. I'm curious to know the outcome!

1. so you're right, it's loading the cgroup1 path, not cgroup2. confirming that the error is open /sys/fs/cgroup/rdma/rdma.current: no such file or directory and that it's coming from the cgroup1 path

2. the kernel supports cgroup2 filesystem but cgroup2 paths are not enabled in the containers and they are using legacy. I'm just confirming this through seeing which filepaths exists in the container.

so now i exec into the container which shows that file of course not existing.

/sys/fs/cgroup # ls /sys/fs/cgroup/rdma
cgroup.clone_children  cgroup.sane_behavior   notify_on_release      tasks
cgroup.procs           kubepods               release_agent

I see a large amount of info under rdma/kubepods/... but these seem to be for other pods? this is the output for tree /sys/fs/cgroup

https://gist.github.com/elee1766/eb9719cfc521b5c4f9bd34de2da090f9

for reference, i am doing the following to try to load the cgroup:

	path := cgroup1.NestedPath("")
	if pid := os.Getpid(); pid == 1 {
		path = cgroup1.RootPath
	}

	cgroup, err := cgroup1.Load(path)

so i guess im still confused. it looks like all the rdma information are under this "rdma/kubepods" path, which i believe is specific to kubernetes. am i using the wrong path here? i dont actually need the RDMA statistics to do what i need to do i think, so maybe i should just try extracting the memory info with another method?

from cgroups.

Can this issue be closed? Doesn't like like an issue with the package.

from cgroups.

yuh

from cgroups.