-----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.
*****************************************************************
