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