Defining the workgroup objectives

[a-aa]

Gerrit Pape wrote:

>On Sun, Jul 31, 2005 at 07:27:24PM +0200, a-aa wrote:
>  
>
>>Gerrit Pape wrote:
>>    
>>
>>>Actually --no-fork isn't an additional task to do, it's doing less;
>>>simply skipping fork, detach, exec.  pid files also are unnecessary when
>>>running under a parent, again less to code to write or run.  What about
>>>knowing when they actually terminate?, the parent knows.
>>>
>>>      
>>>
>>I know that, but this is a problem I've seen "in real life" in the
>>development of initng.
>>dbus - started using --no-fork, as we have no way of knowing if it's
>>"ready" hald is started immediatly after it, and fails on fast system,
>>because dbus hasn't opened the comunication system, so hald can't connect.
>>    
>>
>
>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.

>Regards, Gerrit.
>  
>