Alternative Init System

Tristan Wibberley maihem at maihem.org
Fri Mar 3 21:55:30 GMT 2006


Scott James Remnant wrote:
> On Tue, 2006-02-28 at 08:08 -0600, Rocco Stanzione wrote:


> Sorry, it's time to dispel a myth.
> 
> Replacing the init system will not make any difference to Ubuntu's boot
> time.
> 
> It's simply untrue, and here's why.
> 
> 
> The reason they claim that it makes boot faster is that you can start
> everything at the same time with their system.  Here's the reason that's
> not a benefit:
> 
>  1) You can do exactly the same thing with SysV-style init.  There's no
>     reason that the /etc/init.d/rc script (which processes the rc*.d
>     directories) can't background things when it starts.

If it were that easy all those rc scripts could just daemonise 
themselves, but they can't because they have logical dependencies. 
Currently both the CPU and the disk are underutilised. By using 
dependency knowledge to start nondependent services in parallel you make 
better use of the CPU, affording some improvement (which, as we are at 
35s till gdmgreeter gets stuff on screen for me, could be several 
percent). Furthermore, by letting the process that implements a service 
start up as long as it knows not to attempt to begin using anything it 
depends on you can make better use of the disk too, by keeping the disk 
queues filled with premptive faultingin, etc - this could be a very big win.

>     So we're mostly just talking about rc2.d here...  and if you look at
>     a current dapper bootchart (this one from my laptop[0]):
> 
>     http://people.ubuntu.com/~scott/bootcharts/dapper-20060302-2.png
> 
>     you'll firstly notice that a lot happens in parallel already. 
> 
>     You'll also notice that rc2.d only counts for 10s of the entire boot
>     sequence! and is mostly parallel anyway.

I think that there can be a lot of rc2.d done in parallel with rcS.d if 
it can be determined that the rc2.d services aren't currently configured 
to need parts of rcS.d. That can't be done statically in general, but 
dynamically, upon parsing the configuration files, it can be.

> 
> Now let's look at some reasons to change the Init system, which we are
> considering doing for dapper+1.
> 
> Service Supervision; fantastic ... "keep apache up", and log when it
> goes down.
> 
>   I want to combine that with devices too, "keep podcastd running while
>   my iPod is plugged in" ... "keep bittorrentd running while a network
>   interface is up" ... etc.

Definately - though many services will have their own definitions of 
keeping running (eg network filesystem mounts), that means this must be 
polymorphic. But init will require at least the process monitoring type, 
and that should be available for reuse.

> Cron Replacement: Having separate systems for init, cron, at, inetd,
> etc. all seems wrong to me.  Wouldn't it be great if you could do:
> 
>   "15 minutes after the machine has booted, start postgresql and keep it
>    running until shutdown.  After it has been stopped, run this script
>    to vacuum the databases and copy them to a backup location."

I would agree that there should be a more unified interface available 
for adhoc reconfiguration and that the systems should integrate better, 
but these systems absolutely must be simple and small. I think it would 
be better to define a non-daemon based trigger mechanism (ie, reusing 
existing heavily tested code, eg kernel and UNIX domain sockets). Then 
put a boot trigger that schedules a job via "at" to add postgresql to 
the runlist, similarly put a postgres "normal termination - not shutting 
down" script to vacuum.

Though cron does conceptually configure services, so it should perhaps 
have some level of integration where a crontab entry can depend on 
another service in the system and another service can depend on a 
crontab entry. That's the sort of thing I had in mind for the scheme I 
suggested - You wouldn't start cron as a service, you would start all 
its cronjobs, and cron is just the dependency calculator/namespace 
arbiter/implementation backend for that sort of service.

-- 
Tristan Wibberley




More information about the sounder mailing list