<div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div class="gmail_attr">Hi folks. I continued with my investigation on the best way to solve my problem.<br></div><div class="gmail_attr">As suggested I am calling StartTransientUnit method with dbus (using libdbus), to start a new scope.</div><div class="gmail_attr">Below are my impressions.</div><div dir="ltr" class="gmail_attr"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Firing an async D-Bus packet to systemd should be hardly measurable.<br>
<br>
But note that you can also run your main service as a service, and<br>
then allocate a *single* scope unit for *all* your payloads. </blockquote><div><br></div><div>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.<br></div><div>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.</div><div>There's also a race condition when a job is finishing and another one is starting up, at this point the scope can be destroyed but the main process may not realize it.<br></div><div><br></div><div>I also tried to leave the responsibility of setting up the scope to the forked process itself, which is much easier to code and cleaner because of how the software is designed.</div><div>The forked process just does the dbus call, and when the scope is ready it is moved to the corresponding cgroup (PIDFile=).<br></div><div><br></div><div>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.</div><div>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.</div><div><br></div><div>Problem number two, there's a significant delay since when creating the scope, until it is ready and the pid attached into it. The only way it worked was to put a 'sleep' after the dbus call and make my process wait for the async call to dbus to be materialized. This is really un-elegant.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">That way<br>
you can restart your main service unit independently of the scope<br>
unit, but you only have to issue a single request once for allocating<br>
the scope, and not for each of your payloads.<br>
<br></blockquote><div><br></div><div>Yes. That is solved, I can restart slurmd now, but the other part is not true as I just explained.</div><div>I need to issue new requests every time the scope is cleaned up by systemd.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
But that too means you have to issue a bus call. If you really don't<br>
like talking to systemd this is not going to work of course, but quite<br>
frankly, that's a problem you are making yourself, and I am not<br>
particularly sympathetic to it.<br>
<br></blockquote><div><br></div><div>This is not a problem, but the delay of creating a scope plus it being removed all the time is unacceptable.<br></div><div> </div>My only idea now is to start a scope from the main process, adding a "sleep infinity" pid inside, and discharge anyone to ever creating or calling to dbus.</div><div class="gmail_quote"></div><div class="gmail_quote">If instead I could just ask systemd to delegate a part of the tree for my processes, then everything would be solved.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Do you have any other suggestions?<br></div></div>