-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At some point hitherto, Kevin D. Clark hath spake thusly: > > That isn't quite true. The order is specified. > > "Deterministic but unspecified" is a direct quote from my Solaris > box's man page. Since Solaris is very SYSV-flavored, and since only > documentation I've seen on Linux's init is that it tries to be > compatable with the SYSV init scripts (I have not seen a definitive > statement that clearly states what should happen in this case), I > myself will always assume that Linux's init executes these scripts in > a "deterministic but unspecified" order.
Technically, init doesn't run those scripts at all; they're run by a shell script that init spawns which is specified in /etc/inittab. If you're not happy with the way your system boots, you can change it entirely. There is actually NO predetermined set of scripts that init runs whatsoever (i.e. hard-coded into init); it's defined entirely by /etc/inittab, which is highly configurable. There is, of course, a default behavior defined by your vendor. You can make your system completely ignore the current set of init scripts by changing one line in /etc/inittab (and most likely break your system in the process). That said... > You can make assumptions about the order if you want. However, I > wouldn't recommend doing this if you want your scripts to be > portable. I agree with your point here. Sorry for not being more clear in my previous post; I never did actually make my point. The point was that the original poster had a particular problem (ypxferd starting), on a particular platform (RH 7.2) and wondered if renaming the scripts such that the number of the ypxferd was greater than that of ypserv would make a difference to ypxferd starting in the proper order. Based on the information provided, the answer is absolutely no, it won't. They're already starting in the right order. The original poster should look elsewhere for the source of his trouble with ypxferd starting. > Also, in the absence of a formally documented behavior in this case, > future Linux systems could implement a different behavior, and then > your scripts would die silently, which I assume could cause you to > have a Very Bad Day. I agree that this also is a wise policy; however one has to be able to determine what the current behavior is in order to ensure they start things in the correct order. If there is a question, they only way to determine what that order is would be to look at the scripts that init spawns on the system in question. If the mechanism became somehow different, even slightly, then it's very likely that existing scripts would cease to start in the appropriate order. This would be a problem for any vendor... However, the original poster stated specifically that the system was Red Hat 7.2, which by default behaves as I described. FWIW, I think Sun's "Deterministic but unspecified" is their way of saying, "if it breaks, it's not our fault." The current behavior is not likely to change any time soon (and, at least as far as the order of the execution of init scripts go, is identical on Solaris systems, HP-UX systems, and all other SysV-based systems, AFAIK). The rc script must execute all the S[0-9][0-9]* scripts in the rc.${runlevel} directory. In a shell script, there are two basic methods of obtaining a list of files in a given directory: the output of the ls command, and expanding the shell's metacharacters. Both of these methods conform to the behavior I outlined in the previous post. The likelihood of some vendor using some other mechanism to generate the list of scripts to run is pretty slim, since it would most likely involve writing a seperate C program to readdir(3) the list, which would be a complete waste of effort, and utterly pointless. However, it is far from impossible. Of course, vendors could provide a mechanism which does not execute all the S[0-9][0-9]* scripts in the rc.${runlevel} directory, in which case all bets are off in any event. Another point is that init scripts tend not to be portable anyway, as they generally must account for where things are on the system they are initializing, which varies from vendor to vendor, even amongst Linux vendors, and even between versions of the same OS. So worrying about portability issues in init scripts is really moot. - -- Derek Martin [EMAIL PROTECTED] - --------------------------------------------- I prefer mail encrypted with PGP/GPG! GnuPG Key ID: 0x81CFE75D Retrieve my public key at http://pgp.mit.edu Learn more about it at http://www.gnupg.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8pKzRdjdlQoHP510RAqXyAKC3uOciUtYWlJNzHMqh5G5RNhKUQgCgnNI5 ofVX3TEY9prOD2PlppdlS44= =JC3C -----END PGP SIGNATURE----- ***************************************************************** To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *****************************************************************