On Fr, 01.11.19 08:59, Bhasker C V (bhasker@xxxxxxxxxxxxx) wrote: > > systemd owns the cgroup tree, only subtrees for which delegation is > > explicitly turned on can be managed by other programs, for example for > > the purpose of container managers. > > > > Thus, creating cgroups manually, directly via cgcreate at the top of > > the tree is explicitly not supported. > > > > Use systemd's own concepts, i.e. slice units, direct cgroup access > > bypassing systemd at the top of the tree is explicitly not supported. > > a) Does this mean that running systemd-nspawn from command-line (via > scripts) does not give the user any control over cgroups ? if that is > possible please can you help explaning a bit more ? on cgroupsv1 nspawn delegates access to a subtree of the name=systemd hierarchy to its payload (i.e. none of the other controllers). This is the only thing that is relatively safe to do. on cgroupsv2 nspawn delegates access to a subtree of the full tree, including any controllers, as on cgroupsv2 controller delegation is finally safe. > b) What is the use of --slice= option in systemd-nspawn ? if I can pass > a slice name, I derive that it should be possible (by some means) to > create the slice name with some command ? You can specify any slice you want, systemd will start it as needed on behalf of the nspawn container. Key is: systemd owns the cgroup tree from the top, and delegation of subtrees is the only safe and supported way how other software can write to the cgroup tree, and then only in the subtree they got delegated. Lennart -- Lennart Poettering, Berlin _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel