Re: Debian boot system
On Sat, 07 Oct 2000, Henrique M Holschuh wrote:
> The keywords are "as long as it can be done gracefully."
>
> You need to design a new /etc/init.d/rc which instead of reading the rcS.d
> and rc?.d link farms, reads the paralelized boot sequence from somewhere
> else in /etc AND the old serialized sequence from the proper rc?.d folder,
> merges the two, and executes the resulting list of serialized and
> parellized initscripts.
No. You need to create a Makefile, that can be SEPERATELY and INDEPENDENTLY
managed (forget rc*.d). No merging, not much of anything, just an
auto-generated/maintained makefile, in an easily modifiable format.
> This needs quite a lot of work to be done right, but it is viable... as
> long as you have a *human made* file describing all allowed paralelizations
> (and everything else *especially stuff not in the allowed paralellization
> list* runs serialized as it would be done by the stock rcS script, when
> compared to each other AND the now paralelized initscripts).
Basically, all that needs to be specified, are the dependencies. As I
already have specified roughly, in my Makefile draft (that works fine, btw),
and took about 5 minutes to make.
All the actual work to parallize, is done by make.
> There is not enough information in place (in Debian) to build the
> paralelization list automatically.
True, the Debian packages of daemons and other boot-related software need a
change to support maintaining the boot Makefile.
> See the file-rc package for ideas. Go read the LSB initscript stuff for
> ideas on supplying the machine-readable data required for paralelizing
> stuff automagically. Actually, if you pull this design off, I guess the LSB
> guys might want to see it.
I do not know much about the problems the LSB guys are encountering, but if
they are, their problem is probably not very similar to this one, because in
this one, its quite trivial to specify the obvious dependencies (at least all
that are handled by the sequential boot system).
> I'd suggest writting in a piece of paper a list of all the initscripts in
> your system, in their current start sequence along with the time each one
> takes to start. Now, paralelize it in paper (and make sure not to try to
> run stuff in /usr before /usr is mounted, etc... you'll notice there are
> quite a large number of deadly traps here), and check how much time you
> gained in an ideal machine (two tasks running in parallel do not slow each
> other down -- which is not nearly close to reality, btw). Then post the
> data and results, and we will have a reasonable idea if it is actually
> worth the trouble to implement and deploy.
Well, I've gained 6 out of 30 seconds here (20% or 25% difference, depending
which way you look at it), which is not insignificant. Anyhow, remmember
that the extra speed is just the icing :)
> My off-the-cuff guess is "we don't gain enough time to be worth the
> trouble". But I may be wrong :^P
I think its worth the trouble, especially when you consider a complete
Makefile, containing ALL the dependencies from the rc*.d scripts took minutes
to make and should be quite easy to be software-maintainable.
I think the more graceful error recovery (remmember the
hostname-not-resolvable sendmail problem?), and the extra flexibility (the
ability to easily specify the SPECIFIC dependencies (Current systems, for
example, will sometimes not shutdown correctly, and try to unmount NFS after
shutting down the network, because the order is specified manually, instead
of being deduced from simpler[to humans] dependency specifications)
Eyal Lotem
Reply to: