runit integration

runit integration

[depuis]

Hello,

I've read yesterday the article on linux today about runnit - tried it - I
find it interesting, and I would like to comment a bit...

My background: linux hacker since 1996 (Slackware 3), today using debian etch
on a laptop, rebooting the system each day, so optimising the start phase is a
big win. Furthermore, I use laptop-net to configure programs and services
based upon the network environment: at home, at work, if a WIFI is available, ...

I think that runit should provide some compatibility mechanism with the
existing rc runlevels and /etc/init.d/ scripts. Maintainers carefully polished
those scripts, some are very elaborate, and providing a drop-in for these
scripts is a lot of work: compatibility issues, following the latest version,
and so on.

What does they have in common ? Most use the start-stop-daemon program in
order to control the processes. What about providing some alternative to this
program? But let's think first about what has to be adapted ? Not a lot.
Mostly program invocation. start-stop-daemon expects the called program to
detach(). In the runit context, this should be avoided. A possible solution is
to write a wrapper, like f.i. for gpm:
#!/bin/sh
sv start devfsd || exit 1
EXTRA_ARG="-D" /etc/init.d/gpm start

The idea is to define two environnement vars:
REMOVE_ARG which contains arguments that have to be removed from the final
command line ('--daemon' f.i.)
EXTRA_ARG is a supplemental arg which prevents the called program to detach
itself (program dependent)

The global idea would thus to provide some substitue for start-stop-daemon,
with some wrapper permitting to use the /etc/init.d script "as is". This
substitute would be a mix of runsv and chpst, as the start-stop-daemon can
alter the process state (-u, -g, ...). All the glue logic (this program must
wait that program before starting) would also be concentrated at the same level.

This way, the compatibility would be achieved as:
1) for each entry in /etc/rc2.d, place a symbolic link in /etc/runit/runsvdir/
default/ to a wrapper in /etc/sv
2) for each entry in /etc/init.d, provide a wrapper in /etc/sv wich add and
remove the required args so that the invoqued program does not detach,
together with the required dependencies on other programs.

This way, runit would be a replacement for sysvinit, minimising the migration
and maintenance burden.

I am not subscribed to this list, but I'll follow this discussion through the
archive.

Best regards

Pascal Dupuis



----------
Wordt ook lid van de Scarlet Club via een bestaande Scarlet klant en ontvang cadeaucheques twv EUR 50! Bezoek snel http://www.scarletclub.be
Devenez aussi membre du Club Scarlet via un client Scarlet existant et recevez des cheques cadeaux jusqu'a EUR 50! Surfez vite sur http://www.clubscarlet.be

Re: runit integration

[Charlie Brady]

On Tue, 30 May 2006, depuis wrote:

> The global idea would thus to provide some substitue for start-stop-daemon,
> with some wrapper permitting to use the /etc/init.d script "as is".
...
> This way, runit would be a replacement for sysvinit, minimising the migration
> and maintenance burden.
>
> I am not subscribed to this list, but I'll follow this discussion through the
> archive.

It appears to me that your discussion topic concerns specifically Debian, 
and you should be discussing it with Debian architects or package 
integrators. I don't think you are proposing any change to runit.

---
Charlie

Re: runit integration

[Alex Efros]

Hi!

On Tue, May 30, 2006 at 09:57:52AM +0200, depuis wrote:
> My background: linux hacker since 1996 (Slackware 3), today using debian etch

Hehe... I think most people in this list have similar background. :)
Before trying to find "better solution" like daemontools&runit you should
become unsatisfied with existing mainstream solutions (sysvinit,
start-stop-daemon, scripts in /etc/init.d/, etc.) and this require some years.

> I think that runit should provide some compatibility mechanism with the
> existing rc runlevels and /etc/init.d/ scripts. Maintainers carefully polished
> those scripts, some are very elaborate, and providing a drop-in for these
> scripts is a lot of work: compatibility issues, following the latest version,
> and so on.

I don't think it's possible and good idea. Main reason to use
daemontools/runit - get as secure and as reliable solution as possible.
It's nearly impossible to write complex software which will be secure and
reliable... and because of this daemontools and runit prefer most simplest
and straight solutions. Your idea will add additional level of complexity
and thus result in less security and realiability. 

Also I must say what I disagree with you about quality and goodness of
/etc/init.d/* scripts "carefully polished by maintainers". I worked with
these scripts in Red Hat (versions 6 - 7.3) and Gentoo (1.4 - current)...
and I must say what these scripts contains huge amount of complex, junk code
which slowdown them and contain a lot of bugs.

I'm supporting my own alternative to these scripts in last 5 years. My system
boot using single bash script with ~40 lines. Services started using tiny ./run
files used by daemontools and runit. (Only /etc/init.d/ script which I use is
"vmware" - it's too complex to analyze it and rewrite as ./run... and support
it for each new vmware release.)

This small "boot script" isn't designed to be flexible and compatible
with everything - it's designed to be simple and do everything needed to
boot my system. But... in these years I found this script enough to boot
all my servers and my friend's home systems too - only few lines require
individual tuning per each system:
1) hostname
2) modprobe
3) ifconfig/route
4) loadkeys/setfont
Also this small script is really perfect for learning "how linux boot". :)

Few weeks ago I rewrote this script to add some features:
1) faster boot in initng style (execute some commands in parallel)
   (my script was really fast and before this because it much shorter than
   usual /etc/init.d/ scripts, but now it's few seconds faster :))
2) show detailed information in case of any errors happens
3) ask "press any key in 5 seconds to open shell" if any errors happens
   while boot or shutdown (to allow manual fixing of these errors before
   continuing booting)
4) log everything printed to screen while boot/shutdown into log files -
   to help detecting errors on remote servers
5) support runlevels using kernel params
With all these features script size increased from 40 lines to 200 plus it
now use small library with bash functions (80 lines more). But it's still
much smaller and simpler than usual boot scripts used in all distributions.
(Probably it become smaller in near future because I'll remove 'parallel
booting' feature - few seconds faster booting doesn't important enough to add
this layer of complexity.)

To support my script I carefully review every changes in Gentoo
/etc/init.d/ scripts when new version of sys-apps/baselayout package released.
...In 99% cases they fix their own errors(!) - it's very rare case when I
notice some changes which I should duplicate in my script too - probably once
per year or so!

-- 
			WBR, Alex.

Re: runit integration

[Roy Lanek]

> > I think that runit should provide some compatibility
> > mechanism with the existing rc runlevels and
> > /etc/init.d/ scripts. Maintainers carefully polished
> > those scripts, [...]
>
> I don't think it's possible and good idea. Main reason
> to use daemontools/runit - get as secure and as reliable
> solution as possible. It's nearly impossible to write
> complex software which will be secure and reliable...
> and because of this daemontools and runit prefer most
> simplest and straight solutions. Your idea will add
> additional level of complexity and thus result in less
> security and realiability.
>

Plus, *reality check* [1] if you don't agree, please:


    2.5 STARTUP SCRIPTS

    ...

    Red Hat startup scripts

    Startup scripts are one of things that distinguish
    Linux distributions from each other. Red Hat's are a
    complicated mess; they contain many comments such as

       # stupid hack, but it should work

    and

       # this is broken!

    ...

    SUSE startup scripts

    Startup scripts are one area in which SUSE really
    outshines the other Linux variants [2]. SUSE's
    startup scripts are well organized, robust, and well
    documented. ...

    Debian startup scripts

    If SUSE is the ultimate example of a well-designed,
    well-executed plan for the management of startup
    scripts, Debian is the exact opposite. The Debian
    scripts are fragile, undocumented, and unbelievably
    inconsistent. ...


[1] Evi Nemeth, Garth Snyder, and Trent R. Hein, Linux
    Administration Handbook, Prentice Hall [these fellows
    are authorities on the domain: UNIX sysadmin]

[2] The Linux Administration Handbook covers three Linux
    distributions in detail: Red Hat 7.2, SUSE 7.3,
    Debian 3.0.

    Moreover, I wonder how much the *famous trick* of
    the how-to-boil-a-Bullfrog recipe [slowly increase
    the temperature of the water] has played above ...
    there where Evi et al. write of the--yup--"ultimate
    example of a well-designed, well-executed plan for the
    management of startup scripts."


Cheers,

/Roy Lanek

-- 
########################            bagai air di daun talas                
##### . slackware ######         as if water on a leaf of talas            
##### +-----linux ######  [two things that never get along ... talas has a 
########################   thin waxy layer and therefore is waterproof]