Differences between revisions 27 and 28
Revision 27 as of 2013-10-31 05:35:37
Size: 12042
Editor: ?Thomas Goirand
Comment:
Revision 28 as of 2013-10-31 05:36:17
Size: 12046
Editor: ?Thomas Goirand
Comment:
Deletions are marked like this. Additions are marked like this.
Line 84: Line 84:
, just like we have been used to for years, and that is it, nothing more to it: it auto-magically integrates with the rest of the (traditional) init scripts with correct dependencies as one would expect. Pretty strait forward, for anyone that is used to the old sysv-rc scripts, isn't it? Also, if the above runscript looks a bit like a shell script, it is because it is one! In fact, maintainers can decide to implement or not the start() and stop() functions, and do any complex thing '''if''' they decide to do it (it is of course recommended to avoid it, but sometimes, you really do need to do complex stuff). It is just like we have been used to for years, and that is it, nothing more to it: it auto-magically integrates with the rest of the (traditional) init scripts with correct dependencies as one would expect. Pretty strait forward, for anyone that is used to the old sysv-rc scripts, isn't it? Also, if the above runscript looks a bit like a shell script, it is because it is one! In fact, maintainers can decide to implement or not the start() and stop() functions, and do any complex thing '''if''' they decide to do it (it is of course recommended to avoid it, but sometimes, you really do need to do complex stuff).

Before editing this page, please see the instructions on how debates work. If you are not the maintainer of a position statement, and have a suggestion or change to make, please contact the maintainers.

OpenRC position statement

OpenRC wishes to continue implementing things in a small, simple and efficient way, with the minimum things written in C, and all of the needed features. It also aims at portability. OpenRC is used in Gentoo by default, but also works very well in a number of BSD systems, and it can already work under Debian GNU/kFreeBSD very easily. OpenRC doesn't "take over" the PID 1, it doesn't even implement it, it only implements what's after it: it is a replacement for sysv-rc, not for sysv-init.

Pros

  • OpenRC is straightforward: we don't reinvent the wheel, and just keep what we used to have. update-rc.d, invoke-rc.d, etc just "work" as expected. OpenRC continues to use start-stop-daemon, which it enhanced. Though if we want to switch to the newer interface of OpenRC (rc-update, etc.) it is possible as well.
  • The runscript file format allow both a completely declarative (something like 7 lines should be enough in most cases), but it also supports the old sysv-rc format, with the addition for the support of the LSB headers which has been added last summer by the GSoC studdent. So the transition would be extremely easy: just switch to OpenRC, then slowly move away from sysv-rc style. Nothing to force on anyone.
  • OpenRC is a very good compromise between features and complexity of upstream code. As few as possible code is written in C (this is an upstream choice), the rest of is using scripting (perl, shell...), making it very easy to maintain and debug.
  • OpenRC does not reimplement sysvinit. Yes, this is a good thing. Rewriting the PID 1 process is very dangerous, and adding a lot of code in it is the recipe for disaster. Here, we would continue to reuse what has worked well for decades, and enhance the features later in the boot process.

  • OpenRC has a runlevel namespace. Bye bye runlevel 0, 2 and 4, and say hello to runlevels with comprehensive names "shutdown" (instead of 0), "single" (instead of 1), "reboot" (instead of 6) or "default". Note that this is handled in an extremely easy way using /etc/init.d/rc (which is specific to Debian, for compatibility reasons). OpenRC doesn't even need /etc/inittab to be edited since last September, so we could even keep what we have currently, including any user modified inittab files.
  • Everything stays as we are used to. No huge revolution needed, like rewriting getty and so on for no valid reason (are these tools broken? if so, how???)
  • OpenRC uses control groups to ensure that any service, regardless of its state, can be shut down properly. Though that's not a forced feature, it continues to work on systems who wont CGroups available.
  • OpenRC allows very fast boots. One of upstream author made a proof of concept with booting in 250ms.
  • OpenRC supports nested runlevels this mean you can create complicated system layout by creating specialized runlevels: like default/X11, default/nonetwork, default/network
  • OpenRC upstream is friendly and open as for contributions and for suggestions for feature and portability, they will try to find consensus for the every edge case. They have already been extremely helpful during this summer for the GSoC, with one of the upstream doing the mentoring work as well. They also helped with the porting to kFreeBSD (took only a few hours).
  • OpenRC supports a subset for event-driven action,e.g. services hotpluging (example: http://wiki.gentoo.org/wiki/Iphone_USB_Tethering#udev_trigger)

  • Upstream version of OpenRC provides an intefaces for extending it with additional modules by plugin system of s-s-d (openrc-plymouth is done in that way)
  • OpenRC is designed to do service management and do it well, thus it's acts as a central place and glue for other existing systems that can solve subtasks in the best way. i.e. for pid-1 (sysv5,s6..), supervision(s6/monit), logging utilities. So it's possible to construct scalable solutions on the top of it
  • OpenRC is ready for contribution and work on openrc-daemon: additional package that can provide additional interfaces for OpenRC (e.g. some sort of systemd-compatibility)
  • OpenRC provides librc that can be used in the 3rd party tools that want to extend OpenRC
  • OpenRC tries to use find a consensus between best practives and tools of the target OS and compatibility baseline, that means that core functionallity depends only on compatible POSIX interface, and additional functionallity (modules) may be OS,environment specific
  • OpenRC provides a way to reuse well known unix tools instread on reimplementing them (at/ulimit/)
  • OpenRC provides a way to add service specific commands based on service state (seems should to be in sysv-rc)
  • OpenRC comes along with netifrc - very flexible framework for network configuration
  • OpenRC init scripts are statefull (so you can store additional information while service is alive) but that state is not persistend between service restarts
  • OpenRC tries to reuse existing tools instread of merging tools inside
  • Just like Debian, OpenRC is community driven and doesn't have an agenda driven by commercial interests

Cons

  • OpenRC doesn't have socket activation yet.
  • While some porting efforts has been put on OpenRC, it still needs some more work to get into Debian, namely the rename of /sbin/rc which clashes with the /usr/bin/rc from the "rc" package. Upstream is working on that.
  • No effort yet to port it to Hurd.
  • Not everything from the plans are ready (i.e. there is no clean supervision integration), however work is done
  • No big vendor behind OpenRC, thus there is no paid developers

OpenRC vs Systemd

  • OpenRC is well documented internally and each new feature comes with internal documentation, thus it will be easy for others to hack over OpenRC add features and improve things. To the contrary, even if Systemd has a user documentation (as user: understand API), its internal aren't easy to understand, and the source code has very few comments. The behavior of Systemd components isn't documented at all. Because of this, it makes it very hard to re-implement key components like logind without spending a fair amount of time trying to reverse engineer the source code of Systemd.
  • Systemd is a way too big for what it does. It is our view that 200k+ lines of C just for starting a few daemons is too much, and it makes it very difficult to debug, even with a comprehensive debug mode like Systemd offers.
  • Systemd puts a way too much things inside the PID1 process. This is dangerous because if that process crashes, then the kernel panic. And in fact, it isn't needed to do this. OpenRC, to the contrary, has everything away from the PID1, which it doesn't even re-implement. OpenRC keeps using sysvinit which has work for decades, and and is a replacement for sysv-rc only, which doesn't prevent from implementing features like CGroups.
  • For the package maintainers who cares not only about the Debian GNU/Linux, but also Ubuntu and Debian non-Linux ports, using Systemd will force writing not one, not two, but 3 types of files for the init system: Systemd, Upstart and sysv-rc init scripts (or OpenRC runscripts, if the non-Linux ports decide to switch to that). Therefore, we loose all the benefits from the point of view of the package maintainers.
  • Not only Systemd will not work on non-Linux ports, but its upstream author has clearly stated that they would refuse any patch to aim at that goal. While it is understandable that upstream do not want to add complexity to the code, it is a non-argument since Systemd is very complex already. Also, it is our view that this decision is narrow minded, and not cooperative at all. And this isn't the only case. The fact that Logind in Systemd >= v205 requires Systemd, despite the fact that it is a problem for Ubuntu shows that upstream is just doing what it wants with very little consideration for downstream which doesn't follow the exact path that the Systemd authors are willing to impose. This is unacceptable and Debian should stand against this.

  • Upstream has been border line insulting everyone who isn't adopting Systemd, for example saying "I am pretty sure the Ubuntu guys don't even remotely understand the complexities of this" is not the kind of wording which we should accept, and is a promises a very dangerous future collaboration. As opposed to this, Gentoo upstream for OpenRC have been very nice, and accepted kFreeBSD patches in a mater of hours (after some testing), and released version 0.12.4 of OpenRC with it.
  • Systemd tries to re-invent everything from scratch, when it's not needed. For example, restarting of crashed daemons is currently something OpenRC wants to implement using either s6 or monit, which have been proven to work very well for years. It is a much better approach.
  • Systemd doesn't allow to continue writing shell scripts in the service files. While this may be viewed as a nice feature since it allows easier parsing, in fact it narrows too much the use case, or makes it too complicated to implement complex use cases (because it has to be broken into multiple pieces), while a small script shell inside a runscript is very easy to write. Again, Systemd is trying to reinvent everything, and adding unnecessary complexity when there is no need for it.

OpenRC vs Upstart

  • Even if upstream for Upstart would accept patches for it, there is currently no way to run Upstart on the non-Linux ports, and it is clear that it would take a non-negligible effort to achieve it. There is currently nobody working on that either.

Rebutals

  • From the systemd page: "one of the primary improvenement of OpenRC over the sysinit is cgroups" - it's completelly wrong, cgroups are just a minor feature that can extend some usecases, however pros on this page describes much more features that come with OpenRC (to not duplicate them here). Systemd authors and supporters are trying to let everyone believe that cgroups is the best thing invented since sliced bread, and that it is very complex, which isn't truth.

  • From the systemd page: "The primary selling point of OpenRC is that it is portable. Otherwise, it is merely a sysvinit on steroids.". Well, again, that's not truth, OpenRC does a lot more than just this, this shows very little understanding and investigation from the author of these words.

Example runscript

Because it seems OpenRC is not known enough, I thought it'd be nice to explain how it works, and what a runscript looks like. So I wrote the below runscript for rsyslog in less than 2 or 3 minutes:

 #!/sbin/runscript

 command=/usr/sbin/rsyslogd
 name="enhanced syslogd"

 depend()
 {
         provide rsyslogd syslog
         need $remote_fs $time
 }

The only thing that is needed to replace the old init.d script of rsyslog is replace its content by the above, then do:

update-rc.d rsyslog defaults

It is just like we have been used to for years, and that is it, nothing more to it: it auto-magically integrates with the rest of the (traditional) init scripts with correct dependencies as one would expect. Pretty strait forward, for anyone that is used to the old sysv-rc scripts, isn't it? Also, if the above runscript looks a bit like a shell script, it is because it is one! In fact, maintainers can decide to implement or not the start() and stop() functions, and do any complex thing if they decide to do it (it is of course recommended to avoid it, but sometimes, you really do need to do complex stuff).

Position statement maintainers

  • Thomas Goirand (package maintainer) with help from upstream authors below
  • Alexander Vershilov
  • Patrick Lauer