On Mon, 2021-02-08 at 09:30 +0100, Ulrich Windl wrote: > > > > Ken Gaillot <[email protected]> schrieb am 05.02.2021 um > > > > 16:47 in Nachricht > > <[email protected]>: > > 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 <[email protected]> _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
