[systemd-devel] unable to attach pid to service delegated directory in unified mode after restart

[Lennart Poettering]

On Mi, 16.03.22 16:15, Felip Moll (felip at schedmd.com) wrote:

> On Tue, Mar 15, 2022 at 5:24 PM Michal Koutný <mkoutny at suse.com> wrote:
>
> > On Tue, Mar 15, 2022 at 04:35:12PM +0100, Felip Moll <felip at schedmd.com>
> > wrote:
> > > Meaning that it would be great to have a delegated cgroup subtree without
> > > the need of a service or scope.
> > > Just an empty subtree.
> >
> > It looks appealing to add Delegate= directive to slice units.
> > Firstly, that'd prevent the use of the slice by anything systemd.
> > Then some notion of owner of that subtree would have to be defined (if
> > only for cleanup).
> > That owner would be a process -- bang, you created a service with
> > delegation or a scope with "keepalive" process.
> >
> >
> Correct, this is how the current systemd design works.
> But... what if the concept of owner was irrelevant? What if we could just
> tell systemd, hey, give me /sys/fs/cgroup/mysubdir and never ever touch it
> or do anything to it or pids residing into it.

No, that's not something we will offer. We bind a lot of meaning to
the cgroup concept. i.e. we derive unit info from it, and many things
are based on that. For example any client logging to journald will do
so from a cgroup and we pick that up to know which service logging is
from, and store that away and use it for filtering, for picking
per-unit log settings and so on.

Moreover we need to be able to shutdown all processes on the system in
a systematic way for shutdown, and we do that based on units, and the
ordering between them. Having processes and cgroups that live entirely
independent makes a total mess from this.

And there's a lot more, like resource mgmt: we want that all processes
on the system are placed in a unit of some form so that we can apply
useful resource mgmt to it.

So yes you can have a delegated subtree, if you like and we'll not
interfere with what you do there mostly, but it must be a leaf of our
tree, and we'll "macro manage" it for you, i.e. define a lifetime for
it, and track processes back to it.

Lennart

--
Lennart Poettering, Berlin