Re: RFC: terminate init script when service is ready
Excerpts from Salvo Tomaselli's message of 2012-08-05 15:35:09 -0700:
> Hello,
>
> since services might depend on other services at boot, they must be sorted.
>
> But after doing a "service foo start", and waiting for its termination, we
> don't know if the service has started or not, maybe the process was just
> created and is kept waiting by the sheduler, so when the next service is
> started the service might not really be there.
>
Salvo, thanks for bringing up this issue.
I've been watching the various discussions of boot dependencies
and service dependencies and wondering about this issue for the last
couple of years. I think we all need to consider looking at some guiding
principles before we run off and start solving perceived problems that
may not even exist.
First, the number of actual dependencies between services at boot time
is quite low. There is a necessary sequencing of events that takes place
in all modern operating systems. Mount filesystems, start networking,
setup auth, mount remote filesystems, etc.
But we take this too far. If your auth depends on mysql, and the mysql
service happens to be local, then the only thing that is important is
that mysql is started without waiting for auth, and vice-versa. This
potentially circular dependency should not be a problem. Both services
should be able to "start" without the other, and should just keep trying
the other service.
This is important, because if mysql is not on the box with auth, it will
need to act this way. Otherwise, one no longer needs to define service to
service dependencies, but full blown server to server dependencies. Now
you're using a complicated distributed orchestration system to handle
large scale system bring-up (or medium scale power infrastructure
failures..).
Even if you reject this as dodging the problem, just conider that the
service which claimed to start successfully before the dependent service
starts may go away immediately thereafter, so without making your daemons
resilient, dependencies don't mean much anyway.
In summary:
* Services which "depend" on others should be re-evaluated to see if they
actually "depend" or just need them eventually.
* Consider the case of a service which may or may not be "local"
Reply to: