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@xxxxxxxxxxxx> Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
Attachment:
pgpBrK1RBoGvp.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
