[ClusterLabs Developers] RA as a systemd wrapper -- the right way?

[Andrei Borzenkov]

06.11.2017 22:38, Valentin Vidic пишет:
> On Fri, Oct 13, 2017 at 02:07:33PM +0100, Adam Spiers wrote:
>> I think it depends on exactly what you mean by "synchronous" here. You can
>> start up a daemon, or a process which is responsible for forking into a
>> daemon, but how can you know for sure that a service is really up and
>> running?  Even if the daemon ran for a few seconds, it might die soon after.
>> At what point do you draw the line and say "OK start-up is now over, any
>> failures after this are failures of a running service"?  In that light,
>> "systemctl start" could return at a number of points in the startup process,
>> but there's probably always an element of asynchronicity in there.
>> Interested to hear other opinions on this.
> 
> systemd.service(5) describes a started (running) service depending
> on the service type:
> 
> simple  - systemd will immediately proceed starting follow-up units (after exec)
> forking - systemd will proceed with starting follow-up units as soon as
>           the parent process exits
> oneshot - process has to exit before systemd starts follow-up units
> dbus    - systemd will proceed with starting follow-up units after the
>           D-Bus bus name has been acquired
> notify  - systemd will proceed with starting follow-up units after this
>           notification message has been sent
> 
> Obviously notify is best here

forking, dbus and notify all allow daemon to signal to systemd that
deamon is ready to service request. Unfortunately ...

> but not all daemons implement sending
> sd_notify(READY=1) when they are ready to serve clients.
> 

... as well as not all daemons properly daemonize itself or register on
D-Bus only after they are ready.