Bug#727708: additional OpenRC information
As I mentioned in some of my previous notes, I was unable to evaluate
OpenRC in a meaningful way during my general experiments for a few
reasons. My impression was formed based on previous discussion and what
documentation I could find, which was fairly minimal.
Thomas Goirand sent me considerably more information, including some
details about OpenRC project goals that corrects information in my
original writeup. With his permission, I'm including that here for the
benefit of everyone else who is following this debate.
Thomas, please follow up with anything that I left out or anything else
that you think people should be aware of.
Thomas Goirand <zigo@debian.org> writes:
> I could read at 727708@bugs.debian.org the following from you:
>> If we're going to the effort of
>> replacing init systems and changing our startup scripts, a bare
>> minimum requirement for me is that we at least address the known
>> weaknesses of the sysvinit mechanism, namely:
>> * Lack of integration with kernel-level events to properly order
>> startup.
>> * No mechanism for process monitoring and restarting beyond inittab.
>> * Heavy reliance on shell scripting rather than declarative syntax.
>> * A fork and exit with PID file model for daemon startup.
>> My impression of OpenRC is that it is not attempting to solve these
>> issues in the same way that systemd and upstart are.
> I'm not sure how I should take this. Yes, OpenRC isn't doing "the same
> way", though it's addressing all of the above points. Did you really try
> OpenRC?
> FYI, OpenRC does understand and use cgroups. So that's for the last
> point above. OpenRC does use runscript so this address the "reliance on
> shell scripting rather than declarative syntax". OpenRC is currently
> implementing the use of "monit" so it can monitor and restart processes,
> without reinventing the wheel (monit has been around for years...). As
> much as I know, that part is nearly done, though it needs to have a few
> issues solved (that's what I heard from upstream). I think this is an
> awesome approach to use monit. If you haven't used monit, I would
> recommend you to try it. It's modular and checks for the actual service
> to be running rather than a process running.
> The only thing which it might lack support of would be kernel-level
> events, but I think this is really overrated in the current discussion,
> and also it can be handled most of the time with some very easy to
> implement loops (there's some examples in some of the Gentoo runscripts).
> I think you should re-evaluate OpenRC. Yes, it's not as big as Upstart
> and Systemd (and for me, that's a *good* point, not a bad point), though
> it's not as bad as you describe it.
> If the tech committee was to decide to switch to systemd or upstart, I
> think one of the key decision that could come with it would be to
> deprecate sysv-rc in the favor of OpenRC (with or without mandatory
> support in linux versions of Debian, that's up to the tech-ctte to
> decide...).
and, in another message, some details on how to test:
> FYI, I have just uploaded a new version of OpenRC to the new queue. It's
> IMO back into shape again after fixing the /sbin/rc and /sbin/runscript
> renames, though there's still some corner cases to fix, like "apt-get
> install --reinstall initscripts" fails because there's no runlevels in
> the LSB headers of these scripts (I don't understand why yet though). I
> don't think it'd be hard to fix that one though...
> Anyway, you can try OpenRC from the Git repository on Alioth:
> git clone ssh://git.debian.org/git/collab-maint/openrc.git
> cd openrc
> ./debian/rules make-orig-file
> git-buildpackage
> Then simply dpkg -i the resulting libs and openrc itself. This should
> normally work on both Wheezy and Sid, and in all ports (I tested it on
> kFreeBSD and amd64).
> A quick run-through now. Once you've installed it, it wont know about
> started stuff, so the first reboot will not shutdown correctly. I'm not
> really sure how to fix the first reboot case currently. Though after the
> first reboot, you can try "rc-status" which is a nice stuff.
> I couldn't change "service" utility since it's owned by sysv-utils and
> not OpenRC, though I have updated invoke-rc.d so that it continues to
> update the symlinks in /run/openrc/started (so rc-status will work as
> expected). Unless the sheebang is changed from /bin/sh to
> /sbin/openrc-run in scripts in /etc/init.d, starting the init scripts
> "by hand" with /etc/init.d/<whatever> start/stop will not update the
> status either. All this is fine since everything should be using
> update-rc.d and invoke-rc.d, it's just nice to other ways to start/stop
> daemons work with rc-status support as well for our users.
> I would recommend that you also have a look into /etc/rc.conf, and play
> a bit with the options. Note that "rc_parrallel" does work, even though
> it has an ugly output.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: