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" -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1345386383-sup-7...@fewbar.com
