[systemd-devel] Relationship between cgroup hierarchy and slice names

[Lennart Poettering]

On Di, 03.05.22 20:16, Yeongjin Kwon (yeongjinkwon at gmail.com) wrote:

> Hi,
>
> I'm trying to override the parent slice of a certain slice unit so I can
> reorganize the cgroup hierarchy. I looked into overriding the "Slice"
> property to set the containing slice of the unit, but it seems that
> property does not do anything for slices because the location in the cgroup
> hierarchy and parent are already set by the unit name. The documentation
> says the unit name is composed of a series of words separated by dashes,
> where each word represents a directory in the cgroup hierarchy. If the unit
> name was independent from the location of the slice in the cgroup
> hierarchy, then I would imagine that would make overriding the parent slice
> possible. I tried to find the reason why the slice unit name must strictly
> match the cgroup hierarchy, but I could not come up with an answer after
> searching online and thinking about it myself.
> One possibility for why the slice name must match the hierarchy could be
> naming conflicts. If there are two slices with the same name but in
> different cgroups, they could conflict with each other. But I decided this
> could not be the case, since developers could just avoid the conflicts by
> using the slice naming convention as a convention instead of following it
> as a hard rule. Furthermore, there are several unit types like scopes and
> services which can be organized in the cgroup hierarchy like slices, but
> don't follow the same naming rule. If it was decided that naming conflicts
> in relation to the cgroup hierarchy would not pose a problem for these
> other units, then why was it decided for slices?

Slices are the categorization, and the other unit types are what you
put inside these categories.

If we'd allow putting slices into random other slides without this
being reflected in the name, then first of all you could create
loops. (i.e. put foo.slice inside bar.slice and that back into
foo.slice), and it would pretty much defeat the point of the logic, as
they would suddenly not be purely categories anymore but stuff that
can be put in categories.

> Is there another way to override the location of a slice in the cgroup
> hierarchy? And what is the reason why slice names have to correspond with
> their location in the cgroup hierarchy?

The slice names match 1:1 to the position in the cgroup tree, that's
where they were designed.

We enforce similar rules on naming things btw for .mount, .automount
.swap and .device units: the are also named after paths in the file
system.

Basically our rule is: if the object unit types encapsulates
already have a file system path as name then we don't allow you to
make up a new name, but insist that the unit name is derived from that
pre-existing file system path.

Lennart

--
Lennart Poettering, Berlin