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

[Tom Gundersen]

Hi Patrick,

On Wed, Apr 25, 2012 at 3:03 PM, Patrick Lauer <patrick at gentoo.org> wrote:
> in the last months there have been many discussions about init systems,
> especially systemd. The current state seems to make no one really happy
> - the current Arch Linux init system is a bit minimal and gets the job done, but it's not superawesome.
> There's things like init script dependencies that would be nice to have, but then it's about the smallest of all init systems around.

While dependencies (done in the right way) might have been nice to
have, I don't see this as a major shortcoming of our current system,
and if we are to change away from initscripts the replacement would
have to provide significantly better benefits than that, in my humble
opinion.

> On the other hand systemd is just Not The
> Unix Way, it consolidates everything into one huge process

The systemd daemon is bigger than sysvinit's init and it does more.
However, you make it sound like all the extra featuers of systmed are
implemented in the daemon itself, and this is obviously not the case.
Almost all of the real work during boot is not done in PID1, but in
helper programs (/usr/lib/systemd/systemd-*).

> and forces
> some impossible dependencies (dbus? udev? on my server?! and you expect
> a linux 3.0+ kernel? waaah!).

Are you sure systemd does not work without dbus/udev running or with
older kernels? I have had no reason to test this, but from my
knowledge of the code it should work just fine (obviously you'll lose
the features provided by whatever components you remove). That said,
it is not clear to my what benefit you would hope to get from
excluding tiny daemons such as dbus and udev.

> As an alternative to the One Process For Everything I'd like to ask you to evalute OpenRC as an init system for Arch Linux.

This is a gross misrepresentation. If you want, you could criticise
that the systemd project encompasses many components, but the systemd
process itself is pretty minimal (IMHO).

> While Gentoo is by far the largest user it's definitely not the only one
> - there are the direct derivatives (Sabayon, pentoo, funtoo,
> sysrescuecd, tinhat, ...) and some "foreign" users (Alpine, a debian
> derivative, uses OpenRC)

IMHO, a nice goal would be to increase cross-distro collaboration. How
well are the different major distributions represented in your
contributor base? I think a strong point of systemd is that they have
active contributors from pretty much all major distros (including
gentoo and arch, but possibly with the exception of ubuntu, I'm not
sure).

> * portable - we have it running on Linux, *BSD, and there's no reason
> why it should fail on other unixoid platforms

This is clearly not relevant to Arch Linux.

> * dependency-based init scripts - no need to manually figure out the
> startup order, something like "before apache, after logger" is all you
> need to specify

As the current initscripts maintainer, I have so far not seen any
requests for this feature, though I'm sure it would be nice to have.

> * small footprint - 10k LoC C99, ~3k LoC Posix SH out of the box (plus
> your own init scripts, of course)

+ bash itself (which provides our /bin/sh).

> * friendly responsive upstream (let's figure out how we can cooperate, eh?)

This is nice (and is also very much true of systemd).

> * boring - deterministic reproducable bootup, including interactive mode
> and verbose debug output

How can you be both parallelisable and deterministic?

> For a long time we haven't done any active advertising, but OpenRC is
> now about 5 years old, and it is a drop-in replacement for our previous
> "baselayout" init system (which was started over a decade ago). We don't
> try to take over the world, we just create the best solution for our
> needs. And those go all the way from embedded systems (where you can use
> busybox for all the shell tools) to servers (minimal deps! No mandatory
> udev or dbus!) and desktops (including optional splash screen eyecandy
> and whatever makes you happy).
>
> There's pretty good support for advanced usage like SELinux, built-in
> support for ulimit and cgroups to do per-service resource limits, and it
> even comes with a friendly license (although some might say that a
> 2-clause BSD license it too friendly and promiscuous). And as a random
> bonus feature you get stupid-fast bootup - We've seen <5sec from
> bootloader handover to login prompt (depending on hardware and amount of
> services started, of course) and <5sec for rebooting a kvm guest.

If someone would be willing to evaluate and package openrc so we could
all make an informed decision, I think that would be very useful. That
said, my immediate impression is that it is not a great improvement
over initscripts, and its professed  benefits over systemd seem based
on misconceptions (the "openrc bonus features" table on the webpage
contains serious errors about systemd) or do not apply to Arch, so I
will not be taking this on myself.

I strongly believe that should we move away from intscripts it needs
to be to an event-driven system (such as systemd or upstart) and it
was not clear from the webpage that OpenRC provides this.

Cheers,

Tom