On Sat, 07 Oct 2000, Eyal Lotem wrote: > On Sat, 07 Oct 2000, Henrique M Holschuh wrote: > > 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 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. I don't know what was going through my head when I said the crap above about rc?.d. Here's what one should do if he wants to have any chance to build a sysvlike (uses /etc/init.d/daemon initscripts) approach that works fine with Debian: 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 packaages, 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. 1. is easier, cleaner and safer than mucking around with /sbin/init and /etc/inittab IMHO, but changing the proper stuff in inittab would also work. 2 and 3. are the tools you'll need in your prerm and postinst scripts for the paralell-initscript package :^). 4. is the only way to make the new initsystem graceful and attach it to the current Debian packaging system. > > 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 Yes. However, consider that you'll have to get policy through that make these dependencies a required item for anything that goes in /etc/init.d, and that the LSB guys are doing something like this (so you'll need to sync the efforts with them, or at least attempt to do so -- Debian is supposed to try to support the LSB, no? ). This is a bit more painful and complicated than what you made it out to be IMHO. Not that it's impossible, but it's probably the most troublesome part as it deals with quite a lot of human factors :-) > > 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. 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. > 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. 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. > Well, I've gained 6 out of 30 seconds here (20% or 25% difference, depending Ugh, I misread it. I thought you gained 30 seconds (!). Well, given that your scheme can be done in a Debian-friendly way and that the dependency information you need will also be needed by the LSB, I think it is worth the deployment effort *if* you're going to get the dependency stuff done in such a way that it also provides the information the LSB will eventually ask us to (I don't mean the same format, as the LSB is not finished yet). What machine you used for your measurements? > > 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 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. > 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 :-) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Attachment:
pgpjpCzWEB24t.pgp
Description: PGP signature