Hello. On Mon, Jul 10, 2023 at 02:21:10PM -0700, Ivan Babrou <ivan@xxxxxxxxxxxxxx> wrote: > I want to monitor cgroup changes, so that I can have an up to date map > of inode -> cgroup path, so that I can resolve the value returned from > bpf_get_current_cgroup_id() into something that a human can easily > grasp (think system.slice/nginx.service). Have you considered cgroup_path_from_kernfs_id()? > Currently I do a full sweep to build a map, which doesn't work if a > cgroup is short lived, as it just disappears before I can resolve it. > Unfortunately, systemd recycles cgroups on restart, changing inode > number, so this is a very real issue. So, a historical map of cgroup id -> path is also useful for you, right? (IOW, cgroup_path_from_kernfs_id() is possible but it'd inflate log buffer size if full paths were stored instead of ids.) (I think a similar map would be beneficial for SCM_CGROUP [1] idea too.) > There's also this old wiki page from systemd: > > * https://freedesktop.org/wiki/Software/systemd/Optimizations The page also states: > Last edited Sat 18 May 2013 08:20:38 AM UTC Emptiness notifications via release_agent are so 2016 :-), unified hiearchy has more convenient API [2], this is FTR. My 0.02€, Michal [1] https://uapi-group.org/kernel-features/ [2] https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html?#un-populated-notification
Attachment:
signature.asc
Description: PGP signature
