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

[Yeongjin Kwon]

On Thu, May 5, 2022 at 11:17 AM Lennart Poettering
<lennart at poettering.net> wrote:
>
> On Do, 05.05.22 10:44, Yeongjin Kwon (yeongjinkwon at gmail.com) wrote:
>
> > On Wed, May 4, 2022 at 4:03 AM Lennart Poettering
> > <lennart at poettering.net> wrote:
> > >
> > > The slice names match 1:1 to the position in the cgroup tree, that's
> > > where they were designed.
> > >
> > > 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.
> >
> > I see, thank you for responding.
> >
> > Then would it be possible to somehow override the "Slice" property for
> > all units underneath the slice so that it points to another, custom
> > created slice? Maybe using some conditional overriding mechanism?
>
> You can override the slice for any non-slice unit that is backed by a
> cgroup via a dropin that overrides Slice=.
>
> But maybe I don#t grok your question.

Sorry if I was being unclear.

I want to relocate all non-slice units that are in a slice to a
different slice. I know I can do this by overriding Slice=
individually for each unit with a dropin, but that would be tedious
and prone to flaws. For example, if a package put a unit under the
slice that I wanted to move all units from, then I would have to
override that new unit as well, which I might forget to do. I could
use a post-install script, but that may not be the best solution
either. And so I was wondering if there was a way to automatically
override all units that are under the slice, without having to
override Slice= for each of them individually. Since I haven't seen
anything like this so far, I guess this is also a sort of feature
request.

A possible way to accomplish the above may be to add a conditional
overriding mechanism to systemd. A conditional override would be an
entity that overrides the properties of any unit if the unit matches
the conditions in the override, similarly to a dropin. So I would be
able to override all units that have the Slice property set to the
slice I want to move units from and change it to the slice I want to
move units into.
A possible implementation:
Each conditional override would contain a conditions file and an
overrides file, both under a common directory that represents the
conditional override as a whole. The conditions file would contain a
set of conditions, each being a string with a property set to a value
that can be a pattern/regular expression, like
"Slice=slice-name*.slice". The overrides file would contain a set of
overrides, each being similar to conditions except the value has to be
a concrete string instead of a pattern. A unit would match the
conditions if it matches all or one of the conditions, depending on
how the conditional override is configured. The unit would match a
condition if the value of the unit's property that corresponds with
the property of the condition matches the pattern in the condition. If
a unit matches the conditions, then all the values of the overrides
would replace the existing values of the corresponding properties on
the unit.

For example, if there was a unit that contained:
[Unit]
Description=hello world

[Service]
Slice=user-1000.slice

And there was a conditional override that had:
Conditions file:
[Service]
Slice=user-*.slice

Overrides file:
[Service]
Slice=some-other-slice.slice

Then the unit would be overridden to become:
[Unit]
Description=hello world

[Service]
Slice=some-other-slice.slice

I could also post this on the systemd github as a feature request.

Yeongjin Kwon