[Initscripts-ng-devel] Defining the workgroup objectives

[a-aa]

Gerrit Pape wrote:

>Henrique de Moraes Holschuh wrote:
>  
>
>>1.  Design a distribution-agnostic interface layer for packaging systems
>>    to deal with static order-based (sysv-rc classic), static dependency-based
>>    (init-ng, LSB), dynamic dependency-based (runit?), and hybrid
>>    static-dynamic dependency based initscript subsystems
>>2.  Do the same for Debian (i.e. design the Debian implementation of 
>>    the interface defined in (1)):  
>>3.  Design either an hybrid static-dynamic or a purely dynamic dependency
>>    based initscript subsystem (completely distribution-agnostic)
>>    3a.  Write an implementation of said subsystem from scratch, OR
>>    3b.  Modify init-ng or r-unit to add whatever functionality is needed 
>>         (this need not be a fork. init-ng has a nice plugin
>>         functionality, and all code is to be sent upstream anyway!)
>>4.  Write the interface layer to plug it into Debian
>>5.  Deploy it as a proof-of-concenpt in Debian sid
>>    
>>
>
>Hi, over the last years I wrote the runit init scheme, and worked on
>integrating it into Debian as an alternative to sysvinit; the proof of
>the concept is released with sarge.  There's a major difference though,
>as runit doesn't use ordinary init scripts as found in sysvinit's
>/etc/init.d/ directory, but replaces service startup scripts with (much
>simpler) run scripts.  This has good advantages, and if we already plan
>to change all init scripts in Debian, possibly extending them to carry
>dependency information, why not go one step further and replace them
>with scripts that are simpler to write, and so most probably less
>susceptible to bugs?
>  
>As far as I understand your obejctives, runit already does most of what
>you describe:  1. it's distribution independent and even cross-platform,
>2. Debian integration is half done and still in the works, 3. it's a
>(how you call it) dynmaic dependencies based init scheme, 4. there're
>already packages in Debian using runit, and 5. proof-of-concept is in
>sarge.  But, as I said, it's not done with existing init scripts, but
>with run scripts, that can coexist with the init scripts.
>  
>Now after sarge release, I'm about to continue working on better
>integration into Debian.  The recent runit development release
>introduces a program which can be linked into /etc/init.d/ to provide an
>LSB compliant user interface to control services managed by runit, and
>I'm currently testing how diverting init scripts (note: conffiles)
>works, doesn't look that bad.
>  
>Next step would be to add more run scripts to Debian to replace init
>scripts, best at first in a single package, and, if applicable, later
>move them into the corresponding Debian packages.  Writing these run
>scripts is quite easy, see http://smarden.org/runit/runscripts.html
>
>I personally use runit as init scheme on all Debian systems, as well as
>other systems, and wouldn't mind if we switch to it as a default on
>Debian at some time, obviously.  Help with the further integration of
>runit also would be appreciated.
>
>Thanks, Gerrit.
>  
>
In my opinion, if your gonna reinvent the init.d files, dont use
runscript, it's lacking a few important things.
It for example does exec program --no-fork (or similar) isn't a great
solution.  Most applications using pidfiles or forking are ready when
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.