Re: unable to attach pid to service delegated directory in unified mode after restart

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Di, 15.03.22 17:24, Michal Koutný (mkoutny@xxxxxxxx) wrote:

> On Tue, Mar 15, 2022 at 04:35:12PM +0100, Felip Moll <felip@xxxxxxxxxxx> 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.

Hm? Slice units are *inner* node of *our* cgroup trees. if we'd allow
delegation of that, then we'd could not put stuff inside it, hence it
wouldn't be a slice because it couldn#t contain anything anymore.

> Firstly, that'd prevent the use of the slice by anything systemd.

yeah, precisely? i don't follow. What would a slice with delegation be
that a scope with delegation isn't already?

> Then some notion of owner of that subtree would have to be defined (if
> only for cleanup).

scopes already have that, so why not use that?

> That owner would be a process -- bang, you created a service with
> delegation or a scope with "keepalive" process.

can't parse this.

> (The above is slightly misleading) there could be an alternative of
> something like RemainAfterExit=yes for scopes, i.e. such scopes would
> not be stopped after last process exiting (but systemd would still be in
> charge of cleaning the cgroup after explicit stop request and that'd
> also mark the scope as truly stopped).

Yeah, I'd be fine with adding RemainAfterExit= to scope units

> Such a recycled scope would only be useful via
> org.freedesktop.systemd1.Manager.AttachProcessesToUnit().

Well, if delegation is on, then people don#t really have to use our
API, they can just do that themselves.

Lennart

--
Lennart Poettering, Berlin