Re: sysvinit: rc vs. r2d2 bahavior
Martin Schulze schrieb am Mittwoch, den 30. Dezember 1998:
> > BTW: neither rc from sysvinit nor from file-rc behave exactly in the
> > way Debian policy 3.3.1 describes (r2d2 also doesn't ;-).
> Can you elaborate on this please?
The policy tells us:
When `init' changes runlevel first the targets of the links whose
names starting with a `K' are executed, each with the single
argument `stop', followed by the scripts prefixed with an `S',
each with the single argument `start'.
But this is what rc from sysvinit (and hopefully the rc from your
newly patched file-rc, too) does:
1. Run all K??-scripts in the new runlevel with the parameter "stop"
except when starting up (prevlevel==N).
2. Run all S??-scripts in the new runlevel which are not in
prevlevel as S??-scripts or which are also K??-scripts in the new
runlevel. When going to runlevel 0 or 6, use parameter "stop"
otherwise "start".
I cannot find anything about the "prevelvel" exception in the policy
and I didn't find a word about running all scripts with parameter
"stop" when going to runlevel 0 or 6 there.
So we have three different variants of the behavior now:
a) the one from the policy: this is very simple, but when you have two
nearly identical runlevels with only some small difference, this
will imply that rc tries to start all daemons, which results in
problems when some init.d script doesn't check whether it is run
for the second time with "start" now.
b) the one implemented in sysvinit rc: this gets rid of the multiple
running with "start" by checking the previous level. But this is
only implemented for "start" not for "stop" (why?) and then there's
the additional rule for changing the parameter to "stop" when going
to runlevel 0 or 6 (which seems to be a bug for me, because when I
want "stop" as the parameter I will name the link K?? instead of
S??).
c) the one implemented in r2d2: this is completely logical, but quite
different from the above ones. It's only fault seems to be, that it
came too late...
As you can see b) doesn't implement a). So where's the argument that
doesn't allow me to replace b) by c), which also doesn't implement a)?
Tschoeeee
Roland
--
* roland@spinnaker.rhein.de * http://www.rhein.de/~roland/ *
PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Reply to: