Re: Debian boot system

[Eyal Lotem <eyal@hyperroll.com>]

On Sat, 07 Oct 2000, Henrique M Holschuh wrote:

> > No.  You need to create a Makefile, that can be SEPERATELY and
> > INDEPENDENTLY
>
> No, "separately and independently" management will cause you problems. What
> I mean to say is: You only have available the update-rc.d interface (and,
> if I have my way with Debian's initsystem, you'll have a start-rc.d and
> optional policy-rc.d interfaces as well, but that's a matter for another
> post when I finish testing the code), and you must be able to migrate from
> one init system to the other. Please look at the file-rc package to see how
> its done.
Ok, I have a simple solution to it then :)
The Makefile itself contains all the information and dependencies, and really 
shouldn't be larger than some dozens of K's, at worst.  This Makefile can be 
kept on all systems, and be the actual source of information about the bootup 
system.  This Makefile could be maintained by a simple script that parses it 
and updates its dependencies/rules.
This makefile will have rules for each runlevel, specifying which subset of 
services/etc should be started for that runlevel.
To run the actual init.d scripts from the Makefile, you would use an 
overrid'able variable in the Makefile, that under normal circumstances 
(normal make-booting), would run the scripts, whereas under sysVinit system 
generation, would output the command to run, with an increasing preceding 
number, to identify its location in the order of the boot. (such as 
S20isdnutils S21proftpd S22... etc)

To create the traditional System V system out of that Makefile should be 
fairly simple. All you do is run make on the Makefile, with the 
running-command variable overridden to just print out the names of what to 
run, and you use this output to generate the symlinks pool.

> 1. change /etc/init.d/rc (and maybe /etc/init.d/rcS) to the new initsystem
>    machinery, using dpkg-divert.
> 2. provide script that migrates from old rc?.d to new scheme automatically.
> 3. provide script that migrates from new scheme to old rc?.d automatically,
>    in such a way that doing 2, installing and removing packages, and then
>    doing 3 will not lose initscript information.
> 4. use dpkg-divert to take over update-rc.d (and maybe, if I can prove it
> to be worth the hassle to deploy, take over start-rc.d as well) -- for a
> basic makefile approach you'll only need to take over update-rc.d, I
> suppose.
All these things would just be removing/re-generating the system V init 
scripts, from the Makefile, that will always sit there.

> > True, the Debian packages of daemons and other boot-related software need
> > a change to support maintaining the boot Makefile.
>
> Yes. And I will bet with you that getting this into policy will require a
> careful design and some effort. Your dependency information *needs* to be
> usable for automated tools generating serialized initscripts as well, or it
> isn't likely to be accepted, IMHO.
Well, they supply the information to maintain the Makefile, and the Makefile 
is useful enough to create a System V init system.

> > 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).
>
> Basically, where and how are you going to store the dependencies? (the LSB
> wants it inside comments in the /etc/init.d right now, I think). You also
> need standard, well-defined, "virtual service names" (think of Debian's
> virtual packages) to allow a initscript to request that "I can only be run
> after /usr is mounted, and all networking is up" and stuff like that. I
> think the LSB wants to do away with the sequence numbers, as they're not
> stable across distributions.
Well, I do have 'virtual service names', and I specify the dependencies just 
like you specify dependencies of rules in any Makefile..

> You'll notice that a initscript which can tell you (without rc?.d sequence
> numbers) exactly what it needs to be started/stopped is just what you need
> for your makefile approach to calculate dependencies automatically.
I think that's quite backwards, instead of that, I can have the Makefile tell 
me just what I need, and the system V order should be calculated 
automatically.
> > Well, I've gained 6 out of 30 seconds here (20% or 25% difference,
> > depending
>
> What machine you used for your measurements?
Athlon 750/128MB ram
>
> > 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 give. It is worth the trouble, but please consider the points I made
> above about getting it done *right*. And I suggest you approach this as an
> optional drop-in package which enables your paralell scheme when installed,
> and reverts the system to sysvinit behaviour when removed. Don't worry
> about making it the Debian default.
This could be an optional package, as long as the Makefile is THE true 
specification of dependencies and the core of the boot system, it should be 
fairly simple.
> > 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)
>
> That's what the LSB wants too, I guess. And it is more valuable (to me)
> than the -j2 effect :-)
Same here :)

Eyal Lotem