Any objections to smarden.org tools added to bbox?

[Denis Vlasenko]

On Monday 10 July 2006 11:35, Goetz Bock wrote:
> 
> On Mon, Jul 10 '06 at 09:45, Denis Vlasenko wrote:
> > > > > > I use the djb's daemontools and ucspi-tcp a lot.
> > > > > > However, they are not GPL'ed, but there are very similar
> > > > > > replacements, which are:
> > > > > >
> > > > > > http://smarden.org/runit/
> > > > >
> > > > > [ ... ] instead of runit there is (was?) an minit port to BB,
> > > > > and minit is IMHO a sane way to do what runit tries ;-)
> >
> > runit is none of those things. [ ... ]  
> > The main part of the runit are daemon-controlling tools runsv,
> > runsvdir, svlog.  [ ... ]
> 
> >   613 ?        S      0:00   svscan /var/service
> >   627 ?        S      0:00     supervise fw
> >   628 ?        S      0:00     supervise gpm
> >   629 ?        S      0:01       gpm -D -2 -m /dev/psaux -t ps2
> 
> Why should I want to start an deamon (that better should never die) to
> scan a service directory (svscan) which forks other daemons (supervice)
> which in turn start the real service but need an additional log daemon
> when I can have all that in one package: minit.
> 
> minit scans one directory (normaly /etc/minit) for a list of service to
> start, starts them and restarts them if they die. It also supports
> logging. So you get one daemon which does all what you need 
> 1 (svscan) + n (supervice) + n (optional multilog) daemons for. And
> minit can be used as an init to, so you save one additional process and
> the kernel knows what to do if init should die ;-)

Sounds interesting, I need to look into minit.

Answer to "why supervise?" question:
supervise do not simply restart processes when they die. It provides
means of _controlling_ them (using svc):

stop/restrart a service:
	svc -du /var/service/some_dir

run service once (I use this a lot):
	svc -o /var/service/some_dir

This provides both a convenient tool for manual control
and also for cross-service interactions.

Example:
"dhcp" service starts firewall "service" (with svc -u)
when IP addr is (re)obtained. "firewall" service makes itself
"one-shot" (via svc -o), configures ip addr/routing/firewall
and dies. Imagine the mess of doing it without supervise...

Maybe svscan + supervise*n can be merged into one process.
But maybe djb wanted system to stay modular even
on this level too.
--
vda