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

[Felip Moll]

On Tue, Mar 15, 2022 at 1:29 PM Lennart Poettering <lennart at poettering.net>
wrote:

> On Mo, 14.03.22 23:12, Felip Moll (felip at schedmd.com) wrote:
>
> > > But note that you can also run your main service as a service, and
> > > then allocate a *single* scope unit for *all* your payloads.
> >
> > The main issue is the scope needs a pid attached to it. I thought that
> the
> > scope could live without any process inside, but that's not happening.
> > So every time a user step/job finishes, my main process must take care of
> > it, and launch the scope again on the next coming job.
>
> Leave a stub process around in it. i.e something similar to
> "/bin/sleep infinity".
>
>
Ok.. this was my initial idea.


> > The forked process just does the dbus call, and when the scope is ready
> it
> > is moved to the corresponding cgroup (PIDFile=).
>
> Hmm? PIDFile= is a property of *services*, not *scopes*.
>
>
Sorry I meant PIDs, not PIDFile of course.


> And "scopes" cannot be moved to "cgroups". I cannot parse the above.
>
>
The forked process X does the dbus call to start the scope with
PIDs=$(pidof X), and when the scope is ready,
X is moved into the scope cgroup.


> Did you read up on scopes and services?
>
> See https://systemd.io/CGROUP_DELEGATION/, it explains the concept of
> "scopes". Scopes *have* cgroups, but cannot be moved to "cgroups".
>
>
Yes, it was a misunderstanding of my previous sentence.


> > Problem number one: if other processes are in the scope, the dbus call
> > won't work since I am using the same name all the time, e.g.
> > slurmstepd.scope.
> > So I first need to check if the scope exists and if so put the new
> > slurmstepd process inside. But we still have the race condition, if
> during
> > this phase all steps ends, systemd will do the cleanup.
>
> Leave a stub process around in it.


Ok, then I don't see the real difference of starting up a new service.


> > If instead I could just ask systemd to delegate a part of the tree for my
> > processes, then everything would be solved.
>
> I don't follow. You can enable delegation on the scope. I mean, that's
> the reason I suggested to use a scope.
>
>
Meaning that it would be great to have a delegated cgroup subtree without
the need of a service or scope.
Just an empty subtree.


> > Do you have any other suggestions?
>
> Not really, except maybe: please read up on the documentation, it
> explains a lot of the concepts.
>
>
I've done, I may not be expressing myself perfectly though. I apologize for
that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20220315/90a9962c/attachment.htm>