Debian looks at OpenRC

While Debian has discussed systemd—and Upstart—over the past year or more, that's not the whole story: another potential init replacement has appeared on the debian-devel mailing list. OpenRC is a Gentoo Linux project that was proposed as an alternative to the venerable System V init (sysvinit) that is currently the Debian default. That proposal spawned a long thread, even by debian-devel standards, and a more recent revival of the topic is adding more to the discussion. Though OpenRC has some features that sysvinit lacks, it doesn't bring the number of new features that systemd or Upstart do, so it makes some in the Debian community wonder whether it makes sense to add yet another init replacement into the mix.

OpenRC developer Patrick Lauer suggested that Debian look at OpenRC back in April. It is, he said, a "modern, slim, userfriendly init system with minimal dependencies". It would add support for stateful services (e.g. only one instance will be running at a given time), and dependency-based init scripts, without requiring all of what something like systemd requires ("dbus? udev? on my server?! and you expect a linux 3.0+ kernel? waaah!"). It would be a step up from sysvinit, while still in keeping with the "Unix way". In addition, it supports both Linux and the BSDs, which would eliminate one of the bigger gripes against systemd.

But an incremental improvement to init is not what some are looking for. To many, sysvinit and other shell-script-based solutions have not kept up with the changing hardware and kernel environment, so an event-based init is the right way forward. As Arto Jantunen put it:

As might be expected, there are plenty of folks who don't quite see things that way. While there are vocal advocates of systemd—and rather less vocal Upstart advocates—there are numerous opponents as well. OpenRC might provide something of a middle ground as Roger Leigh described:

To that end, Leigh started looking more closely at OpenRC, with an eye toward packaging it for Debian. One problem that he noted early on was the lack of support for LSB dependencies in the init scripts. The LSB headers are comments that specify the runtime dependencies for each init script. OpenRC has its own dependency system, but Leigh believed that LSB dependency handling could be added to OpenRC.

Over the intervening months, that is exactly what happened. On August 9, Benda Xu posted an intent to package (ITP) for OpenRC, which restarted the discussion. Leigh noted that Xu had gotten OpenRC to work with the LSB-based Debian init scripts, so that it could be a replacement for the sysv-rc package (which handles changing runlevels, starting and stopping services, and so on), while still using the init and scripts provided by sysvinit underneath. In addition, the OpenRC upstream is working on ways to allow other tools to access its dependencies, which would allow systemd or others to use OpenRC scripts. He concluded:

Supporting multiple init systems is not without a cost, of course. There are now (or soon will be) at least four different kinds of configuration for init "scripts" (sysvinit, OpenRC, systemd, Upstart). While systemd and Upstart can use existing init scripts, and OpenRC is getting there as well, doing so loses much of the benefit of the alternatives. To some, there is simply an impedance mismatch between static dependency-based systems and those that are event-driven—though systemd advocates might not completely agree with the "event-driven" characterization. As Russ Allbery put it:

Allbery said that these kinds of problems were not easily solvable with the existing init scripts: "The alternative is to add [significant] additional complexity to every package like those listed above that needs the network to loop and retry if the network isn't available when it first starts." That would be a "huge waste of effort".

One of the potential blockers for systemd, though, has been its reliance on Linux-only features, which makes it problematic for Debian GNU/kFreeBSD (and Debian GNU/Hurd down the road). OpenRC might not provide all of the features that systemd (and Upstart) do, but it could be enough of an upgrade to sysvinit that it makes sense to make that switch. That might actually pave the way for an event-driven init default for Debian GNU/Linux as Philip Hands described:

At least some in the Debian community are particularly annoyed by the systemd team's unwillingness to take patches for portability to kernels beyond Linux. That led Adam Borowski to jokingly dismiss OpenRC because it lacks "a hostile upstream". More seriously, Leigh pointed out that OpenRC uses some of the same features as systemd, but does so with portability in mind:

Others see it somewhat differently (of course). Maintaining a package for multiple platforms has its costs, and for a low-level package like systemd those costs may be rather high. It's not that the systemd upstream is "hostile", according to Matthias Klumpp, but that systemd is difficult to port and its developers don't want to maintain an #ifdef-heavy code base. Instead, the systemd folks suggest forking systemd and maintaining a parallel repository for any ports. But that isn't easy, Klumpp said: "So far nobody has created a non-Linux fork of systemd, and the reason is mainly that it is too much work."

There is also the underlying question of just how much "choice" there should be in a distribution's init system. Setting aside the "Linux is about choice" disagreements that always seem to arise in these kinds of discussions, there is a real question about how many different options Debian can and should support. As Allbery noted, Debian does not support switching to a different C library, for example. But Faidon Liambotis countered that it was only because no one had ever tried to show the "viability and usefulness" of switching to something other than glibc. Furthermore, things like kFreeBSD or building Debian with LLVM did not come about by some kind of consensus, rather it was due to someone deciding to make it work.

For init systems, though, Leigh believes that if OpenRC proves to be a viable replacement, it should supplant sysv-rc, rather than providing a choice. It wouldn't resolve the question of defaulting to an event-driven init (for Linux at least), but it would allow the rest of the Debian community to "get on with life while the upstart and systemd folk take chunks out of one another for a decade or so", as Hands put it.

While Linux may not be about choice exactly, its users are certainly accustomed to being able to fairly easily switch between different technologies: distributions, kernels, desktops, mail servers, web browsers, and so on. In some respects, Debian users are even more acclimated to a wide variety of choices. Its package repository is renowned for its breadth, and the distribution as a whole seems intent on providing choices whenever it is technically feasible. It is too soon to say for sure, but the addition of OpenRC may well provide a bridge that would upgrade init for those who aren't convinced of the "event-driven future", while staying out of the way of the systemd and Upstart efforts.