[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: sysvinit: rc vs. r2d2 behavior



On Wed, Dec 30, 1998 at 12:30:40PM +0100, Roland Rosenfeld wrote:
<snip>
> 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.

The stop/start switch is IMHO bogus, and blatantly violates the rule of
least surprise..

As far as the 'prevlevel' exception, its not needed, it makes things
more complex, and one could argue that it could break some cases..
(IE someone purposely shuts something down, and then later changes
runlevel, the runlevel change should restart it)
> 
> 
> 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.

The answer is quite simple on the scripts which don't check, file
severity important bugs against them (They are /NOT/ suitable for
release in that state) for violation of policy, which last I looked
required them to handle such cases cleanly..

> 
> 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??).

I think we need to modify sysvinit to fit policy, though the previous
level exception will probably require a debate on -policy to iron out.

As far as the start/stop issues, aieee! Thats going to be murder to
change everything to be where they need to be, but, alas, it really is
needed for sanity.. :/
> 
> 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...

Logical but completely different is nice, but would be next to impossible
to make the change over, and for how much benefit?
> 
> 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)?

Someone needs to file a bug against sysvinit, sigh, this could be
interesting, anyone else care to file?

I'd rather someone who knows the guts of the issues involved file the
bug reports, but if nobody else wants to file them I will..

Zephaniah E, Hull.
> 
> 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
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> 

-- 
 PGP EA5198D1-Zephaniah E, Hull <warp@whitestar.soark.net>-GPG E65A7801
    Keys available at http://whitestar.soark.net/~warp/public_keys.
           CCs of replies from mailing lists are encouraged.

Attachment: pgpPhHXq4NSTl.pgp
Description: PGP signature


Reply to: