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

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Do, 24.03.22 00:45, Felip Moll (felip@xxxxxxxxxxx) wrote:

> Hi, some days ago we were talking about this:
>
>
> > > 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.
> >
> > If you want to synchronize in the cgroup creation to complete just
> > wait for the JobRemoved bus signal for the job returned by
> > StartTransientUnit().
> >
> >
> StartTransientUnit returns a string to a job object path. To call
> JobRemoved I need the job id, so the easier way to get it is to strip the
> last part of the returned string from StartTransientUnit job object path.
> Am I right?

JobRemoved is a signal, not a method call. i.e. not something you
call, but you are notified about. And it originates from an object and
objects have object paths in D-Bus.

> Once I have the job id, I can then subscribe to JobRemoved bus signal for
> the recently created job, but what happens if during the time I am
> obtaining the ID or parsing the output, the job is finished? Will I lose
> the signal?

Yes. D-Bus sucks that way. You ave to subscribe to all jobs first, and
the filte rout the ones you don#t want.

> What is the correct order of doing a StartTransientUnit and wait for the
> job to be finished (done, failed, whatever) ?

first subscribe to JobRemoved, then issue StartTransientUnit, and then
wait until you see JobRemoved for the unit you just started.

Lennart

--
Lennart Poettering, Berlin