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

Lennart Poettering lennart at poettering.net
Tue May 10 12:48:06 UTC 2022


On Do, 05.05.22 19:12, Yeongjin Kwon (yeongjinkwon at gmail.com) wrote:

> 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.

There's no such feature.

But how would it even work? if you say "everything in foo.slice should
now be in bar.slice". but once you say it, these units would be in
bar.slice so the rule doesn't apply anymore... it's messy to use a
property as matching parameter that is also the parameter you want to
change, because then things cannot possibly be declarative/idempotent
anymore...

Note that systemd units allow hierarchal drop-ins. i.e. the drop-in
directory "foo-.service.d/" is read for all units matching the glob
pattern "foo-*.service". Thus, if you want to migrate a bunch of units
at once, you could do so — as long as you enforce a naming scheme that
makes all units that "belong together" use the same name prefix.

In the past we had some discussion to have a global setting
DefaultSlice=, which would allow changing which slice to default to
for units that don't specify it. (i.e instead of system.slice). But I
am not convinced this really makes too much sense...

Anyway, I don't really grok the usecase...

Lennart

--
Lennart Poettering, Berlin


More information about the systemd-devel mailing list