<HTML><BODY><div>Lennart,<br><br>> the systemd cgroupfs hierarchy is private property of systemd, and container managers are supposed to follow this logic if they want to interfere with this: <a href="https://systemd.io/CGROUP_DELEGATION/">https://systemd.io/CGROUP_DELEGATION/</a><br><br>I see. Thank you for the link. I’ve also read the <a href="https://systemd.io/CONTAINER_INTERFACE/">https://systemd.io/CONTAINER_INTERFACE/</a><br><br>Seems having the follwing records in the root of named systemd hieararchy is what systemd doesn’t expect:<div># ls -ld /sys/fs/cgroup/systemd/docker/<br>drwxr-xr-x. 2 root root 0 Nov 10 09:58 /sys/fs/cgroup/systemd/docker/<br><br># ls -ld /sys/fs/cgroup/systemd/kubepods/<br>drwxr-xr-x. 4 root root 0 Jul 16 08:06 /sys/fs/cgroup/systemd/kubepods/</div><div> </div>It is hard to believe that docker/k8s and systemd have not reached agreement.<br>I’ve asked k8s folks. Maybe there are some reasons for that.<br><a href="https://groups.google.com/g/kubernetes-sig-node/c/Fuf3OUJ6OvI">https://groups.google.com/g/kubernetes-sig-node/c/Fuf3OUJ6OvI</a><br><a href="https://kubernetes.slack.com/archives/C0BP8PW9G/p1605274049105100">https://kubernetes.slack.com/archives/C0BP8PW9G/p1605274049105100</a><br><br>Let’s see what might be the reason.<br>If you have any ideas why k8s/docker create cgroups in the root of systemd named hierarchy, please share.<br>Maybe it will bring us faster to common ground.<br><br><br> <blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;">Friday, November 13, 2020 3:50 PM +03:00 from Lennart Poettering <lennart@poettering.net>:<br> <div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_16052718570365683316_BODY">On Do, 12.11.20 20:05, Andrei Enshin (b1os@bk.ru) wrote:<br> <div class="mail-quote-collapse">><br>> Hello systemd folks,<br>><br>> I have a k8s cluster on CoreOS which uses systemd.<br>> There are few nodes after k8s update started to have (maybe it was before) a problem with the following mount:<br>><br>> mount ID 2826<br>> parent ID 26<br>> major:minor 0:23<br>> root /kubepods/burstable/pod7ffde41a-fa85-4b01-8023-69a4e4b50c55/8842def241fac72cb34fdce90297b632f098289270fa92ec04643837f5748c15<br>> mount point <br>> /sys/fs/cgroup/systemd/kubepods/burstable/pod7ffde41a-fa85-4b01-8023-69a4e4b50c55/8842def241fac72cb34fdce90297b632f098289270fa92ec04643837f5748c15</div><br>I am not sure what this is, but your software is doing somethign very<br>wrong here. the systemd cgroupfs hierarchy is private property of<br>systemd, and container managers are supposed to follow this logic if<br>they want to interfere with this:<br><br><a href="https://systemd.io/CGROUP_DELEGATION/" target="_blank">https://systemd.io/CGROUP_DELEGATION/</a><br><br>The mount point above suggests they are doing something at the top of<br>the cgroup tree, instead of their delegated subtree. That's simply<br>broken and not supported. The kubernetes people really should know<br>better, as this is documented in detail.<br><br>Please contact the kubernetes folks and ask them to follow the<br>documented interfaces.<br><br>Lennart<br><br>--<br>Lennart Poettering, Berlin</div></div></div></div></blockquote> <div> </div><div data-signature-widget="container"><div data-signature-widget="content"><p>---</p><p>Best Regards,<br>Andrei Enshin</p></div></div><div> </div></div></BODY></HTML>