Alternative Init System
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
> 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):
> 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.
More information about the sounder