Defining the workgroup objectives

Sven Mueller debian at incase.de
Tue Aug 9 13:58:41 UTC 2005


martin f krafft wrote on 09/08/2005 09:47:

>> There are several problems still, the least of which is
>> /var/service, which we might just as well move to /etc/runit, if you
>> ask me.


Seconded.


>> I am also not too much in favour of continuous starting of
>> runscripts in random order until the runscript itself decides that
>> it's ready to go. Part of the reasons is that it burns cycles
>> unnecessarily. The other part is that it seems kinda hackish.


Too true again. That's my impression as well, runit seems to be a
straight-forward implementation of a babysitter daemon for a
(configurable) selection of services. That's not a bad thing, but it
doesn't implement a dependency system. And (as you say below) it doesn't
implement a runlevel equivalent.


>> Another thing I miss is an abstraction to virtual names. Let's stick
>> with postgrey: postfix itself does not care whether postgrey listens
>> at 60000, or greylist-ng, or pregray or whatever. As long as the
>> service "smtp-greylist-daemon" is provided, it should start. I think
>> we would want to create something akin to virtual packages, or see
>> if we can reuse the Debian virtual package names.


I don't think we can reuse those too easily. But then again, we could
reuse the Debian alternatives system to point to the right X-is-up
testing scripts if we use testing scripts for dependencies. If we don't
use dependency testing scripts, but a configuration file, we could
define aliases or something similar in that file and/or allow
dependencies to specify a number of possible services. Something like:

/etc/services/dependencies
spampd: mysql|postgresql
postfix: postfix-greylist-daemon, spampd
postgrey: mysql

/etc/services/aliases
postfix-greylist-daemon: postgrey|greylist-ng

With some script-interface to add or remove a service from the aliases-list.


>> Is there any way to get rid of the statically linked diet libc? E.g.
>> by reimplementing runit in perl, shell, or python?


Hmm, are we trying to build a replacement for /sbin/init or just some
supplement which starts most services after /sbin/init has done all the
basic initialisation stuff (like mounting /usr)? If we want a
replacement, we would have to go the compiled binary way (C or C++) and
can't use perl or python. We could use shell however.


>> I would like to see different runlevels even with runit.


Me too. Or some equivalent which can use _names_ instead of numbers for
the runlevel. Of course those names could simply be "1" "2" etc. by default.

cu,
sven

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 186 bytes
Desc: OpenPGP digital signature
Url : http://lists.alioth.debian.org/pipermail/initscripts-ng-devel/attachments/20050809/a3b24a65/signature.pgp


More information about the initscripts-ng-devel mailing list