Re: RFC: OpenRC as Init System for Debian

[Patrick Lauer <patrick@gentoo.org>]

On 05/02/12 04:55, Carlos Alberto Lopez Perez wrote:
> On 27/04/12 19:33, Tollef Fog Heen wrote:
>> ]] Martin Wuertele 
>>
>>> * Josselin Mouette <joss@debian.org> [2012-04-27 09:53]:
>>>
>>>> Le jeudi 26 avril 2012 à 22:29 +0200, Svante Signell a écrit : 
>>>>>> Yes of course, because event-driven init systems have *always* been
>>>>>> *only* about mounting USB devices. 
>>>>> Then explain the _real_ reasons for having an event driven boot system!
>>>> BECAUSE THE LINUX KERNEL IS EVENT DRIVEN.
>>> That's a reason for udev/mdev, however I still fail to see why this
>>> results in the requirement for an event based boot process. 
>> A trivial example is $remote_fs isn't satisfied until /srv/somewhere is
>> mounted and /srv/somewhere comes off iscsi, which means it requires
>> networking to be up, which means network drivers loaded, etc.  So the
>> event «network driver loaded» causes ifup to be spawned, which causes
>> $network to be satisfied which causes the iscsi daemons to be started
>> which causes mount to be called.
>>
> A better example is bluetooth.
>
> In my Debian system I have /usr/sbin/bluetoothd running and I don't have
> any bluetooth devices on my system... So wouldn't be better that instead
> of launching the bluetooth daemon and let it waiting for the day that I
> plug a USB bluetooth device (and still I never did that) to just launch
> this daemon only when the kernel detects a bluetooth device?
You mean like udev triggering an init script?

Yeah, that's kinda cool. If only someone actually used that ohwait :)

>
>
> """
> For a fast and efficient boot-up two things are crucial:
>
> * To start less.
Which means less mandatory deps. I'm down to ~2 seconds for userspace on
most of my servers, or about 15 seconds if a stupid service like mysql
is involved that just takes 5 seconds to figure out what to do next.

Before that the kernel takes about 2-3 seconds, that's hard to get
faster. And anyway the BIOS will fiddle around and do nothing useful for
30-90 seconds - userspace is by far the smallest chunk of that, but for
some reason everyone tries to make that faster. How strange.
> * And to start more in parallel.
Been there done that. It gets very hard to define dependencies in a way
that is cycle-free and efficient.
And you can hit the funny spot where IO becomes your bottleneck, which
is mildly silly.
>
> What does that mean? Starting less means starting fewer services or
> deferring the starting of services until they are actually needed.
Deferring is bad and should be optional. Makes failures so much more
exciting because they happen at random times later where no one is
watching them and things get annoying to untangle ...
>  There
> are some services where we know that they will be required sooner or
> later (syslog, D-Bus system bus, etc.), but for many others this isn't
> the case. For example, bluetoothd does not need to be running unless a
> bluetooth dongle is actually plugged in or an application wants to talk
> to its D-Bus interfaces. Same for a printing system: unless the machine
> physically is connected to a printer, or an application wants to print
> something, there is no need to run a printing daemon such as CUPS.
> Avahi: if the machine is not connected to a network, there is no need to
> run Avahi, unless some application wants to use its APIs.
Or you enjoy parallel bootup where cupsd starting has no effect on the
rest, because ... parallel 'n stuff.
>  And even SSH:
> as long as nobody wants to contact your machine there is no need to run
> it, as long as it is then started on the first connection. (And admit
> it, on most machines where sshd might be listening somebody connects to
> it only every other month or so.)
Yeah, and if the machine slows down because it is swapping I can't login
because suddenly you need to start services ... hey, with cgroups you
can even make openssh OOM-safe and with a guaranteed share of system
resources. *that* is awesomesauce.
>
> Starting more in parallel means that if we have to run something, we
> should not serialize its start-up (as sysvinit does), but run it all at
> the same time, so that the available CPU and disk IO bandwidth is maxed
> out, and hence the overall start-up time minimized.
> """ http://0pointer.de/blog/projects/systemd.html
>
"as sysvinit does" ... no, sysvinit doesn't.

Sysvinit calls whatever is defined in /etc/inittab for the default
runlevel (usually 5). And what that thing does ... your choice, man. You
could even use monit or runit to start your init scripts.
Well, or you could be a bore and just use OpenRC (run /sbin rc default
from inittab), set rc_parallel="YES" in /etc/rc.conf and be happy.

Yeah, I know, such a conservative boring working solution, where's the
excitement? :)

Have a nice day,

Patrick