[ClusterLabs Developers] RA as a systemd wrapper -- the right way?
arvidjaar at gmail.com
Mon Nov 6 17:02:28 EST 2017
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.
More information about the Developers