init: API
Lamont R. Peterson
lamont at gurulabs.com
Sun Nov 20 06:25:42 UTC 2005
On Saturday 19 November 2005 03:18am, Nicolas Mailhot wrote:
> Le vendredi 18 novembre 2005 à 19:16 -0800, Pete Zaitcev a écrit :
[snip]
> Just use vim for syntax highlighting and xmllint to check the result.
xmllint? Have you ever used it for any serious XML work? It isn't very
accurate. With all the XML I've done (which is not huge amounts, but a fair
bit), xmllint is flat out wrong about 1/3 to 1/2 of the time; usually it says
something is wrong when it fact, it is right. When it is "correct" about
there being something wrong 4/5 times it give error messages that are not
even close to where the problem is actually occurring.
> 100% light-weight CLI solution.
Not really, given the problems with xmllint.
-----
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.
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.
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.
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.
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.
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 :) .
--
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051119/1007eab8/attachment.sig>
More information about the fedora-devel-list
mailing list