Defining the workgroup objectives

[a-aa]

Gerrit Pape wrote:

>On Sun, Jul 31, 2005 at 05:58:56PM +0200, a-aa wrote:
>  
>
>>In my opinion, if your gonna reinvent the init.d files, dont use
>>runscript, it's lacking a few important things.
>>    
>>
>I don't think so, and can tell from experience.
>
>  
>
>>It for example does exec program --no-fork (or similar) isn't a great
>>solution.  Most applications using pidfiles or forking are ready when
>>    
>>
>
>It's a good thing: you have service daemons running under a parent
>process exactly knowing the process id of the service daemon, no need
>for pid files; you have a well-defined interface to control the daemons
>through the parent, even with different privileges; you have a
>guaranteed process state for the service daemons, regardless whether
>they start at boot time, or start or restart anytime while the system is
>up; see http://smarden.org/runit/benefits.html
>
>  
>
>>they've forked and the pidfile is up, so using --no-fork isn't a good
>>dependable way to start them in parallel, because there is no real way
>>of knowing when they are actually started.
>>    
>>
>
>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.

>You might be interested in this web page
> http://homepages.tesco.net/~J.deBoynePollard/FGA/unix-daemon-design-mistakes-to-avoid.html
>
>Regards, Gerrit.
>  
>