[ClusterLabs] Antw: Re: Antw: [EXT] Re: Q: starting systemd resources

[Ken Gaillot]

On Mon, 2021-02-08 at 09:30 +0100, Ulrich Windl wrote:
> > > > Ken Gaillot <kgaillot at redhat.com> schrieb am 05.02.2021 um
> > > > 16:47 in Nachricht
> 
> <7247097610e6ab4f3a44a7648e0acf32fbdb9937.camel at redhat.com>:
> 
> Hi!
> 
> ...
> > > Doesn't systemctl return a proper exit status?
> > 
> > It does, but we don't use systemctl, we use the systemd C library
> > interface. And unfortunately, our current implementation does not
> > use
> > it optimally.
> > 
> > The current design is based on initiating the start, then polling
> > the
> > the status periodically until it reports active.
> 
> So the start function you are using is asynchronous? Otherwise I
> don't see the need of polling independent from a probe/monitor
> operation.

Correct, that's what the systemd C API offers us.

> > 
> > A better design would be to initiate the start, then listen for
> > systemd
> > DBus signals that report when the start is complete. However that
> > would
> > be a significant redesign, and developer time is not available for
> > it.
> 
> Compared to an OCF RA start where you wait until the start returns
> some result, why do you do it so much differently for systemd?
> Because in systemd it's all different? ;-)

The *Pacemaker* start waits until the polling comes back as active
before returning success, so at the RA level it's the same. It's just
the underlying implementation that's asynchronous because of how the
systemd C API is defined. If we move to listening for DBus signals, we
can improve the timing and reliability, but it would still be
asynchronous.

OCF isn't really different -- under the hood, Pacemaker forks a new
process to run an OCF agent, and asynchronously waits for that process 
to exit before returning a result.

> ...
> 
> Regards,
> Ulrich
-- 
Ken Gaillot <kgaillot at redhat.com>