[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: OpenRC as Init System for Debian

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

Reply to: