On Sat, 2005-11-19 at 23:25 -0700, Lamont R. Peterson wrote: > On Saturday 19 November 2005 03:18am, Nicolas Mailhot wrote: > > Le vendredi 18 novembre 2005 à 19:16 -0800, Pete Zaitcev a écrit : > [snip] > BTW: It's interesting how this part of the thread has developed into a > conversation about XML in general. Just to bring some focus back, we *were* > talking about SysV Init scripts and the need to represent service > inter-relationships in order to better facilitate intelligent, "automated" > parallelized startup/shutdown of the system. > On that note, I believe that XML would be a grave mistake for this > application. We need to stick with shell scripts, there is just too much > that would be thrown away with any other choice. I fully agree. > > What about having a separate file from the Init script for dependency > information? Bad idea...keeping each services' critical data in one file > makes life much easier. I second that. Create a main service manager scripts, that loads each configuration file (by . /etc/smc/smb.conf), and then calls the predefined service start/stop functions. I wrote similar system for a certain embedded Linux I worked on, and managed to get a fully running Linux, BIOS to PostgreSQL in around 30 seconds. (~35 with DHCP). While the system was no-where near as complex as Fedora's SysV init (though it did include dependencies, priorities and a watchdog), it was lightening fast and fairly flexible. Better yet, it is fairly easy to create a bash based service watchdog that eats minimal amount of CPU time. > > Yes, we already have /etc/sysconfig/* files, which allows the *local* > administrator to make customization decisions about how the services are > started (i.e. daemon command line options). You might, therefore, think that > we could put service dependency information into these /etc/sysconfig/* > files, but those files are for "local customization*, not global/general > configuration. Better to put that data into the /etc/init.d/* file. > > How should it be formated? Well, the LSB already says, "like this:". So > let's make this really simple and make it easier for people to test the new > system while still working with the old. Yes, the LSB SysV Init dependency > format has it's limitations, but we do not need much complexity; quite the > opposite, in fact. So here's my idea: > > 1. Service inter-dependency data in SysV Init scripts...either (A) in the LSB > format, or (B) by adding "# depends:" and "# sibling:" fields for chkconfig. I understand depend. But why do we need sibling? To force restart of all sibling processes in case of single process crash? > > 2. The "new" Init process can be configured to scan all /etc/init.d/* files > and provide monitoring and alerting support (kind of like it already has > respawn). Another custom chkconfig-like field could be used to indicate that > this service "wants" to be monitored. Could that line go > into /etc/sysconfig/* files? I guess that depends on whether the decision to > have init watch the service should be made by the local administrator or > "not". Does this need to be decided on a service by service basis? > > 3. A "new-and-improved" rc that can use the LSB and/or new chkconfig-like > entries to "do the right thing". Part of that would be parallel startup. > > 4. Select S and K numbers for the /etc/rc?.d/ files that place all services > that can be started "in parallel" at the same number. I'm still doubtful that parallel start will be beneficial on single CPU machines. > > 5. Benchmark. > > As others have pointed out, we do not have numbers to back up the assertion > that this will work. I am already highly certain that it will. Have any of > you tried turning on SUSE's parallel start-up in their newer releases? > Theirs is based on make + some very "deep voodoo" shell scripts. The > advantage of their system is that you can flip it on and still use the same > LSB meta-data in the SysV Init scripts basically in the way we've all been > doing things for years. Flip the switch, and the shell-voodoo + make > combination comes into play and the boot up process is nearly 3 times faster, > in the cases where I have played with it; sorry, no hard numbers for you. It'll be nice if we could see numbers. > > The point is...these suggestions take the simple approach; they let us stop > guessing and actually do something conclusive. It also requires only a few > relatively minor changes to init & rc. > > OK. Let the comments start rolling in :) . Gilboa -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
