> On Di, 12.05.20 14:21, Fedora Development ML > (devel(a)lists.fedoraproject.org) wrote: > > ... > > cgroupsv2 is built around a single-writer scheme. That means any > section of the tree shall only have a singler writer, i.e. one > subsystem 'owning' it. On systemd systems the root of the tree is > owned by systemd, it's the single writer of it. Other software may > read from the tree but not make changes to it. > > You can ask systemd for a delegated subtree of the main cgroup tree > however. You can do this via Delegate=yes in a service file, or by > doing "systemd-run --scope -p Delegate=yes -t /bin/bash" on the > command line. If you do that you get your own subtree in which you can > do whatever you want, and systemd will not step on your toes. > > Making changes to the top-level cgroup tree, i.e. stepping into > systemd's explicitly owned territory means voiding your warranty > though. > > This design choice is made by the cgroupsv2 subsystem in the kernel > btw, it's not something systemd came up with. > > It's documented here in all detail: > https://systemd.io/CGROUP_DELEGATION > > hence, if libcgroups wants to do cgroup stuff it really needs to ask > systemd for delegation first (or be invoked inside a service where > something else asked for it). If it doesn't then it's simply broken. Thank you for the explanation. The page you linked is more than clear upfront: Intended audience: hackers working on userspace subsystems that require direct cgroup access, such as container managers and similar. I will keep that in mind. > > In general, I am not sure why one would even want the cgroup tools on > a systemd system though. I just wrote something along those lines to Tom, the onus is on me to catch-up and leverage what is available. > We should provide most of it natively anyway, > though possibly in a different manner. > > Lennart > > -- > Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
