Re: RFC: OpenRC as Init System for Debian
On Mon, May 07, 2012 at 09:30:42PM +0800, Patrick Lauer wrote:
> On 04/26/12 00:42, Roger Leigh wrote:
> > On Wed, Apr 25, 2012 at 08:52:59PM +0800, Patrick Lauer wrote:
> >> I'd like to ask you to evaluate OpenRC as candidate to replace the "old"
> >> have-always-been-there sysvinit/insserv init scripts in Debian.
> > While as others have mentioned that ideally a more dynamic init
> > system such as systemd or upstart is where I think the general
> > consensus is
> Define "dynamic" please, and don't use "lines of code changed per month"
> as metric ;)
> As long as we don't even agree what that (and "event driven") mean it'll
> be needlessly confusing for all involved to discuss without a shared
> vocabulary.
>From the dependency side, it looks like OpenRC has most of that
functionality covered; it can start other services as required in
order to bring up dependencies needed by a service before starting
it.
What systemd has that (AFAICS) OpenRC and sysvinit/startpar/insserv
do not, is a global view of the entire running system. That is, when
you run an OpenRC script, it can trigger dependencies recursively,
but it doesn't have itself a dependency graph of the entire set of
available services. systemd, in comparision, can read all the unit
files and has a complete picture of the entire system. So in a sense,
it has a higher-level view of the system--mountpoints and other stuff
can go into the dependency graph, which solves som of the issues with
mounting of network filesystems and bringing up interfaces, and
starting the necessary services etc.
The dynamic part is AFAICT a few pieces:
1) socket-based service activation
2) dbus-based service activation
[and I guess others, e.g. udev, initctl, etc.]
All of these are effectively the same conceptually; an external
trigger causes systemd to execute actions. The socket-based
activation is essentially the same as inetd, but because it's
integrated into systemd it can fit this into the dependency graph,
as well as starting all the listeners in a single step, and then
allowing the actual services to be started on demand. The dbus
activation is similar (I'm less familiar with it), but working over
dbus instead. I guess this is needed for integration with desktop
environments (e.g. bluetooth), in response to user actions.
The other really nice thing that systemd has is a unified means of
configuring the process environment for all services, e.g. resource
limits, umask, etc. which are all set up before starting the service.
That's not to say that OpenRC couldn't be made to do any of these
things, it being a superset of the functionality currently provided.
But it would probably require replacement of sysvinit as init with a
daemon like systemd which could keep track of all the dependencies
and other stuff, and respond to signals of various types to trigger
events. It could convievably query each init script for its
dependencies to build up the complete picture of the system; this
could cater for reading from multiple sources like systemd does:
OpenRC scripts, LSB scripts, systemd units, /etc/fstab, and
/etc/inittab etc.
The above type of central control is one source of confusion in our
initial discussions regarding LSB script support; I initially
assumed that this was how OpenRC deps were implemented, which would
have made LSB script support simpler. However, it would be possible
to extend the OpenRC functions to trigger the central coordinating
service rather than doing things themselves, as well as to configure
the per-service process environment. (I was planning on bringing
this sort of possibility up, but wanted to learn more about the
design of OpenRC and get it working first on Debian with LSB scripts
so I had a clear understanding of what would or would not be
possible or appropriate.)
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
Reply to: