|
|
Subscribe / Log in / New account

Distributions

Debian looks at OpenRC

By Jake Edge
August 22, 2012

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:

Reliability in the case of modern kernels and modern hardware means event based, not static. The hardware in a modern computer comes and goes as it pleases (usb devices being the worst example, but scanning for pci or sata busses and loading drivers isn't exactly instant in all cases either), and the kernel has little choice in the matter. It can either sleep until "everything is surely detected by now" before passing control to userspace, or pass control and the problem along (by providing event notification when the device set changes). The kernel made its choice about this years ago, and we have been living on borrowed time and kludges since then.

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:

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 (we all know that sysvinit/insserv is flawed in many ways, even if we can't agree on what should replace it), there is always the possibility of having OpenRC as a sysvinit alternative in the interim, or potentially as a systemd/upstart alternative longer term.

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:

Working on getting OpenRC to work on Debian is not without value. For me, the entire point of the exercise is to explore the [feasibility] to port it and evaluate it as an alternative/replacement for sysv-rc; this is almost completely orthogonal to work on systemd/upstart, which will for the most part be unaffected by this.

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:

And lest someone think this is a theoretical exercise, we *frequently* get bugs filed against packages like OpenAFS, the Kerberos KDCs, or OpenLDAP that are boot-order-dependent and network-dependent and either don't start or start in unuseful ways or at unuseful times because of lack of event notification for when interfaces are *actually* ready or when network devices are *really* available.

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:

As a largely disinterested observer, it seems that this might at least provide a route to being able to provide enough support of the the features that make the systemd/upstart folk dizzy with excitement, such that non-linux platforms don't end up acting as a blocker for one of those two to be adopted for linux, while OpenRC covers non-linux enough so that init-agnostic start-up scripts can work anywhere.

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:

OpenRC can (on Linux) use cgroups and hence do some of the more advanced stuff that systemd does. Yet it still runs on other platforms. This is in part due to the fact that OpenRC is written to be portable, while the systemd developers have an [astoundingly] bad attitude with respect to this. It would be perfectly possible for systemd to support other platforms if they really wanted to; it probably wouldn't even be that hard.

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.

Comments (25 posted)

Brief items

Distribution quote of the week

Nurse Euca will run before any install and take everyone’s temperature, offer an aspirin or a splint where needed — or will let you know if one of your requirements is Dead On Arrival. (“I’m sorry, Doctor, but em1 appears to be in septic shock. I recommend against resuscitation.”) (That’s totally gonna be an error message, btw.)
-- Greg DeKoenigsberg

Comments (none posted)

Newsletters and articles of interest

Distribution newsletters

Comments (none posted)

6.0: The beginning of the end for AV Linux (The H)

Glen MacArthur recently released AV Linux 6.0. AV Linux is a popular distribution for audio and video production. The H reports that 6.0 will be the final release. "While the project has received positive feedback from users, MacArthur says that version 6.0 will be the final release of AV Linux for a number of reasons, most notably a lack of donations. The distribution is being provided "as-is" and will not be updated and maintained, although the developer notes that tech support will be provided in the project's forums for one year. "Obviously this will be a disappointment to some users, however before you walk away I urge you to try the latest ISO and let it prove it's own worth," said MacArthur, adding that, "people who want to install and create multimedia will not be disappointed... people who live for the next software update will be better served by KXStudio or Dream Studio, both excellent projects in their own right."

Comments (13 posted)

Raspberry Pi now comes in Firefox OS flavour (The Register)

The Register reports that Mozilla's Firefox OS has been successfully ported to run on the diminutive Raspberry Pi platform. The port was apparently done by a Nokia employee, but is a side project: "Romashin seems to have undertaken this work off his own bat. So let’s stick to lame puns on “pie”, shall we, rather than wondering what Redmond will say about Nokia playing with an OS other than Windows Phone."

Comments (5 posted)

Page editor: Rebecca Sobol
Next page: Development>>


Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds