On Di, 29.06.21 20:29, McKay, Sean (sean.mckay@xxxxxxx) wrote: > Hi there, > > I have (what I think will be) an easy question: Are there any > circumstances or configuration behaviors under which we would expect > the init.scope cgroup to not get created (still on v1, if > applicable). I suspect the answer is no, but I wanted to verify. init.scope is where PID 1 moves itself into early on if it#s not in there already. Note that if PID 1 is started in a cgroup somewhere down the tree it will create the init.scope cgroup below *that*, and not at the top. It's just that the kernel by default will of course run PID 1 in the top cgroup. Which means if you have a weird initrd that moves things around, then PID 1 might live in some arbitrarily chose subcrgoup. > Context if you care: we've got a source based distribution (yocto > project based. 3.0, specifically) running systemd 243 (not > supported, I know) and I've just discovered that init.scope is not > created on our systems. I assume that this is a bug and something > that we've broken, but it seemed easy enough to ask if there are any > circumstances where it might be expected before I get out my shovel > and start digging. Thanks! -Sean McKay Really old systemd versions didn't do init.scope. They ran PID 1 in the top-level cgroup. We introduced the init.scope mostly to fulfill cgroupv2's requirement of not running processes in inner cgroups. We introduced it on both cgroupsv1 and cgroupvs2 when we added it, even though not strictly necessary on the former, to minimize behavioural differences. maybe your old systemd is just +that* old? Lennart -- Lennart Poettering, Berlin _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel