[systemd-devel] unable to attach pid to service delegated directory in unified mode after restart
Lennart Poettering
lennart at poettering.net
Wed Mar 16 16:06:28 UTC 2022
On Di, 15.03.22 17:24, 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.
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
More information about the systemd-devel
mailing list