Greetings,

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 debian init system is a bit minimal and doesn't even do
stateful services in an elegant way (e.g. /etc/init.d/apache2 start;
/etc/init.d/apache2 start). On the other hand systemd is just Not The
Unix Way, it consolidates everything into one huge process and forces
some imppossible dependencies (dbus? udev? on my server?! and you expect
a linux 3.0+ kernel? waaah!). But "everyone else" is moving to systemd,
so where does that leave us? (One might notice that "everyone else" is
just Fedora/RHEL at the moment, with (open)SuSE tagging along, and most
others still not committed to a migration yet)

I'd like to ask you to evaluate OpenRC as candidate to replace the "old"
have-always-been-there sysvinit/insserv init scripts in Debian.

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)

What we offer you is a modern, slim, userfriendly init system with
minimal dependencies. All you need is a C99 compiler and a posix sh!
The list of features is long and tedious (see
http://wiki.gentoo.org/wiki/OpenRC ), but the critical bits are:

* portable - we have it running on Linux, *BSD, and there's no reason
why it should fail on other unixoid platforms
* 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
* small footprint - 10k LoC C99, ~3k LoC Posix SH out of the box (plus
your own init scripts, of course)
* friendly responsive upstream (let's figure out how we can cooperate, eh?)
* boring - deterministic reproducable bootup, including interactive mode
and verbose debug output

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.

Should you decide to switch (or just evaluate if switching is possible /
makes sense) you'll get full support from us in migrating init scripts
and figuring out all the nontrivial changes. Just visit us on IRC (
#openrc on irc.freenode.net), send us a mail ( openrc@gentoo.org ) or
meet us for a beer or two.

Thanks for your consideration,

Patrick Lauer

Gentoo Developer, OpenRC co-maintainer


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F97F3AB.4090801@gentoo.org">http://lists.debian.org/4F97F3AB.4090801@gentoo.org

Patrick Lauer <patrick@gentoo.org> writes:
> 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 debian init system is a bit minimal and doesn't even do
> stateful services in an elegant way (e.g. /etc/init.d/apache2 start;
> /etc/init.d/apache2 start). On the other hand systemd is just Not The
> Unix Way, it consolidates everything into one huge process and forces
> some imppossible dependencies (dbus? udev? on my server?! and you expect
> a linux 3.0+ kernel? waaah!). But "everyone else" is moving to systemd,
> so where does that leave us? (One might notice that "everyone else" is
> just Fedora/RHEL at the moment, with (open)SuSE tagging along, and most
> others still not committed to a migration yet)
>
> I'd like to ask you to evaluate OpenRC as candidate to replace the "old"
> have-always-been-there sysvinit/insserv init scripts in Debian.

Based on this text it seems to me that OpenRC doesn't do anything that
our current init wouldn't do (we already have dependencies and
concurrent startup), and also that it wouldn't solve the problem upstart
and systemd were created to solve. I might be wrong here since I don't
know OpenRC, so correct me if I'm missing something.

It seems to me that many of the conversations about init systems have
been missing the point quite badly as well, so it might be that this
isn't obvious.

To me the point is clearly reliable bootup, not speed or dependencies
themselves (the dependencies are required for implementing reliable
bootup, and the speed is produced as a side effect of correctness).

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.

--
Arto Jantunen


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87ehrcc4kw.fsf@kirika.int.wmdata.fi">http://lists.debian.org/87ehrcc4kw.fsf@kirika.int.wmdata.fi

On 04/25/12 21:40, Arto Jantunen wrote:
[snip]
>> I'd like to ask you to evaluate OpenRC as candidate to replace the "old"
>> have-always-been-there sysvinit/insserv init scripts in Debian.
>
> Based on this text it seems to me that OpenRC doesn't do anything that
> our current init wouldn't do (we already have dependencies and
> concurrent startup),

* stateful init scripts (e.g. /etc/init.d/apache2 start
-> * WARNING: apache2 has already been started)

* nice management tools (rc-status shows what init scripts are in the
current runlevel and their current state)

And many small features that just make life a bit easier like named
runlevels (so it's "single" instead of "1")


> and also that it wouldn't solve the problem upstart
> and systemd were created to solve. I might be wrong here since I don't
> know OpenRC, so correct me if I'm missing something.

Both upstart and systemd suffer from NIH and (imo) fail to be simple and
reliable. But you are right, OpenRC is not revolutionary, it's more a
consequent evolution that happened as we were slowly fixing all the
little bugs that annoyed us.

>
> It seems to me that many of the conversations about init systems have
> been missing the point quite badly as well, so it might be that this
> isn't obvious.
>
> To me the point is clearly reliable bootup, not speed or dependencies
> themselves (the dependencies are required for implementing reliable
> bootup, and the speed is produced as a side effect of correctness).

In my experience OpenRC has the most reliable and deterministic bootup,
and it makes it easy to figure out your current state (is apache still
running? Should it be running?)

Performance and all that is just a bonus for me, always correct is more
important than fast


> 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.

I mildly disagree there. The init system doesn't need to know about such
things, it only provides the actions. The device manager (what used to
be udev+hal, then was udev/gudev and is now systemd) should handle the
policy. So - connecting a usb wlan card triggers a kernel event, which
udev processes, and udev then decides from its rules what action to take
- say /etc/init.d/net.wlan0 start
(Although there is a considerable overlap between rules and actions)

For me there's no reason why udev / mdev can't stay standalone,
integrating it into the startup scripts doesn't feel right.

Have a nice day,

Patrick Lauer







--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F980E8E.6020309@gentoo.org">http://lists.debian.org/4F980E8E.6020309@gentoo.org

I wonder no one mention Solaris SMF :-)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F981885.2020807@gmail.com">http://lists.debian.org/4F981885.2020807@gmail.com

Igor Pashev <pashev.igor@gmail.com> writes:

> I wonder no one mention Solaris SMF :-)

Does a free port of that thing exist, which we could use?

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87fwbru8p7.fsf@algernon.balabit">http://lists.debian.org/87fwbru8p7.fsf@algernon.balabit

Hi,

as a very first step I suggest to get OpenRC packaged for Debian. Until then,
your suggestion is a bit like suggesting to use the hurd as the default kernel
;-)


cheers,
Holger


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201204251019.44062.holger@layer-acht.org">http://lists.debian.org/201204251019.44062.holger@layer-acht.org

On Wed, Apr 25, 2012 at 08:52:59PM +0800, Patrick Lauer wrote:
> I'd like to ask you to evaluate OpenRC as candidate to replace the "old"
> have-always-been-there sysvinit/insserv init scripts in Debian.

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.

Initially, we'd want to package it and make sure that it works
with our existing init scripts, before it could be considered as
the default. (Obviously we can't make any promises about that;
we already have a number of alternative inits, and OpenRC would be
one of several.)

I think the key requirement is that it can function as a drop-in
replacement for sysvinit/insserv. Are there any important
differences? Does it treat LSB dependencies the same as insserv?
How about old scripts lacking dependency info? Are the dependencies
computed dynamically or generated? (insserv hooks into update-rc.d)


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120425164212.GW28734@codelibre.net">http://lists.debian.org/20120425164212.GW28734@codelibre.net

On Apr 25, Patrick Lauer <patrick@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
Not true. systemd and upstart do not make /everybody/ happy, but nothing
does.

> I'd like to ask you to evaluate OpenRC as candidate to replace the "old"
> have-always-been-there sysvinit/insserv init scripts in Debian.
What we need is an event-driven init system, anything else will just
make us waste more time.

> What we offer you is a modern, slim, userfriendly init system with
Sorry, no. upstart, systemd or the Apple thing are modern init systems,
this one is not.
But I agree that it would have been nice 5 years ago.

--
ciao,
Marco

On Wed, 2012-04-25 at 19:49 +0200, Marco d'Itri wrote:
> On Apr 25, Patrick Lauer <patrick@gentoo.org> wrote:
>
...
> > I'd like to ask you to evaluate OpenRC as candidate to replace the "old"
> > have-always-been-there sysvinit/insserv init scripts in Debian.
> What we need is an event-driven init system, anything else will just
> make us waste more time.

And the _technical_ motivation for that is?? Please give a link or explain!

> > What we offer you is a modern, slim, userfriendly init system with
> Sorry, no. upstart, systemd or the Apple thing are modern init systems,
> this one is not

> But I agree that it would have been nice 5 years ago.

See above!



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1335380710.3707.118.camel@hp.my.own.domain">http://lists.debian.org/1335380710.3707.118.camel@hp.my.own.domain

On 26/04/2012 03:05, Svante Signell wrote:
> On Wed, 2012-04-25 at 19:49 +0200, Marco d'Itri wrote:
>> On Apr 25, Patrick Lauer <patrick@gentoo.org> wrote:
>>
> ...
>>> I'd like to ask you to evaluate OpenRC as candidate to replace the "old"
>>> have-always-been-there sysvinit/insserv init scripts in Debian.
>> What we need is an event-driven init system, anything else will just
>> make us waste more time.
>
> And the _technical_ motivation for that is?? Please give a link or explain!
>
>>> What we offer you is a modern, slim, userfriendly init system with
>> Sorry, no. upstart, systemd or the Apple thing are modern init systems,
>> this one is not
>
>> But I agree that it would have been nice 5 years ago.
>
> See above!

I think Arto Jantunen explained it pretty well earlier in this thread:
> 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.


--
Kind regards,
Loong Jin