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

[Lennart Poettering]

On Mi, 16.03.22 17:30, Felip Moll (felip at schedmd.com) wrote:

> > > (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
> >
> >
> Note that what Michal is saying is "something like RemainAfterExit=yes for
> scopes", which means systemd would NOT clean up the cgroup tree when there
> are no processes inside.
> AFAIK RemainAfterExit for services actually does cleanup the cgroup tree if
> there are no more processes in it.

It doesn't do that if delegation is on (iirc, if not I'd consider that
a bug). Same logic should apply here.

> If that behavior of keeping the cgroup tree even if there are no pids is
> what you agree with, then I coincide is a good idea to include this option
> to scopes.

Yes, that is what I was suggesting this would do.

> > > 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.
>
> That's not exact. If slurmd (my main process) forks a slurmstepd (child
> process) and I want to move slurmstepd into a delegated subtree from the
> scope I already created, I must use AttachProcessesToUnit(), isn't that
> true?

depends on your privs. You can just move it yourself if you have
enough privs.

See commit msg in 6592b9759cae509b407a3b49603498468bf5d276

> Or are you saying that I can just migrate processes wildly without
> informing systemd and just doing an 'echo > cgroup.procs' from one
> non-delegated tree to my delegated subtree?

yeah, you can do that.

Note that (independently of systemd) you shouldn't migrate stuff to
aggressively, since it fucks up kernel resource accounting. i.e. it is
wise to minimize process migration in cgroups and always migrate plus
shortly after exec(), or even better do a clone(CLONE_INTO_CGROUP) –
though unfortunately the latter cannot work with glibc right now :-(.

i.e. keeping processes that already "have history" around for a long
time after migration kinda sucks.

Lennart

--
Lennart Poettering, Berlin