Defining the workgroup objectives

[a-aa]

Gerrit Pape wrote:

>On Sun, Jul 31, 2005 at 08:07:46PM +0200, a-aa wrote:
>  
>
>>Gerrit Pape wrote:
>>    
>>
>>>This is inconsistent: if "hald" fails, then you have a way of knowing
>>>whether it's ready; it's not ready because "hald" fails.  Find out why
>>>"hald" fails and use this check to test whether it's ready.  This seems
>>>to be a special case you describe, can well be handled with runit's 
>>>dependency concept though.
>>>
>>>      
>>>
>>I can't remember right now what other things I've seen do this, but it
>>has happened, and my testbox has only a fairly small amount of basic
>>packages.  How would you handle this "cleanly" in runit?
>>
>>    
>>
>>>Waiting for dbus to detach isn't a reliable solution, maybe for system
>>>startup, but not for the system's uptime: dbus could terminate
>>>immediately after fork and exec; or it could terminate any time later,
>>>causing "hold" also to fail later.  You can handle this when running the
>>>daemons under a parent.
>>> 
>>>      
>>>
>>Of course, but it's not our job to make sure a daemon runs for 3 hours,
>>it's our job to start it, and only start things depending on it when
>>it's properly started.
>>    
>>
>
>Well, I don't think so.  init is not just about starting up services in
>a specific order; it's also about stopping services, starting up
>services while uptime (think package installation), controlling services
>(such as restart or signals), and taking services down at system
>shutdown.  Doing all this, it's just a small step to also supervise
>service daemons, and detect unintended shutdown (eg. crashes).
>
>runit defines the state of a service, not just the startup.  A service
>defined to be up will be started at boot-time, and, while uptime, will 
>be restarted if it terminates, as long as it is defined to be up.  Of
>course there also are other states.
>
>A good dependency concept not only finds out the right order to startup
>services, but also to shut them down.  A real good dependency system
>takes service dependencies also into account when a single service is
>taken down (think removing packages) or terminates unintentionally while
>system uptime.
>
>Regarding your question above, this would be handled automatically by
>runit, as it will restart the "hold" service if it fails, until it
>succeeds eventually.  If you don't think that's a "clean" solution, or
>the startup of this specific service takes a lot of resources, add a
>check for the dependency to the top of the run script (before execing
>into the daemon), and either wait, or simply exit to be restarted.  This
>also works with cross-machine dependencies, btw.
>
>System startup is just a minor part of init's duties in my opinion.
>
>Regards, Gerrit.
>  
>
I absolutly agree with that, but think about this.
If you have 5 services, all of which depends on the "master" being up. 
And that will try to connect to it's master at start.

How do you deal with that?  A solution like this for all of them?:

daemon --no-fork &
while ls <file that indicates it's up, or netcat to see if port is
open?>; do
  sleep 1
done
fg 1

As executing them in order wont do anything.  You can't execute a daemon
with --no-fork and expect it to be up a millisecond after, then anything
depending on it has a high chance of failure.