init: API

[Gilboa Davara]

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