[arch-general] RFC: OpenRC as init system for Arch

[Tom Gundersen]

On Mon, May 7, 2012 at 6:54 PM, Kevin Chadwick <ma1l1ists at yahoo.co.uk> wrote:
> On Mon, 7 May 2012 17:39:35 +0200
> Tom Gundersen wrote:
>
>> An event-driven init system would turn this on its head, and never
>> wait for "all the things to be ready", rather start things on-demand
>> and whenever their dependencies are satisfied. This leads to a much
>> simpler system (from the admin/system daemon developers point of
>> view), but it requires the init system to keep closer control over the
>> state of the system, listen to events, etc.
>
> But a much more complicated one from the admin/system user in terms
> of troubleshooting. Also in terms of auditing. Rather than seeing what
> ports are listening by default, we have to investigate (hopefully in
> one location) to know what will be listened to upon any future possible
> event. I hope efforts made to make that very clear.

Daemons that are ported to work with the new systemd socket activation
(see dbus and udev for examples, there are also plenty others) will
allow this very easily.

The way it works is that the sockets will be listened to at all times,
even before the daemons are running. So starting a daemon would not,
if it uses pure socket activation, open any new sockets. Once your
daemon does eventually start, the socket will be passed to it so it
can handle any connections that came in while it was not yet ready to
accept them.

> Thanks for the explanation, are there some examples of what this means
> we can do that couldn't be done in any way outside of init before.

I guess anything is always possible (bash is Turing complete, right
;-) ). That said, we'll get lots of simplifications and can drop old
workarounds:

We can remove arbitrary timeouts or retry-loops. Especially when it
comes to usb storage we often have issues with booting too fast, so
that the device is not yet ready when we try to mount it. That would
no longer be a problem.

Currently, we support a relatively limited number of storage
configurations (combinations of lvm/md/dm/encryption). With systemd we
now deal with encrypted devices in a nice way, but there is still some
way to go before the whole storage stack is event-driven. Once this is
the case there will no longer be any restrictions on how you combine
storage devices, on top of that the code to do this will be much
simpler than the current code.

Also, by the fact that things are more finegrained we can deal with
some dependencies which were not possible (without a refactor) before.
One example could be that we want to first mount /var, then read our
random-seed from /var so we can use it as a random encryption key for
/tmp. If we mount /tmp and /var at the same time that's not going to
work :-) Obviously we can sort this out by refactoring our initscripts
a bit, but we could think of more complicated scenarios, where you do
not want to have a rigid a system as what our current initscripts are.

Btw, I don't know how any of this compares to OpenRC as I have not
looked at it at all (I was not impressed by the PR campaign...).

-t