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

Re: sysvinit: rc vs. r2d2 behavior



On Thu, 31 Dec 1998, Zephaniah E, Hull wrote:

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

This is what I see, too. But it is implemented, so I fear that it was
intensional. Maybe someone knows what the intension was? Otherwise we
make break something be removing this exception...

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

This is what _you_ expect. I expect only those scripts to be started
which _need_ to be started. I fear that I'm the only person who really 
uses different runlevels so I will give you an example where I use
this for:
Sometimes it may be a good idea to unload the ISDN modules (because of 
installing newer ones or because of trouble on the S0 bus). For this I 
need to switch of mgetty and vboxgetty which work on some ttyI*
devices (otherwise it isn't possible to unload the modules). The
easiest way to realize this is to use two different runlevels which
differ in the start of the gettys above and which start/stop the
isdnutils package (isdnlog, isdnctrl,...).
For this only one or two scripts in /etc/init.d have to be run with
start/stop (more isn't useful), but when I do this in the way the
policy requests, many scripts are run with start, with costs time but
doesn't make much sense to me.

So I like the way, sysvinit rc and file-rc work at the moment and I
even like more the way r2d2 works.

BTW: Nobody seems to have a problem with the actual behavior, so I
don't see, why we should make it worse. Instead we should simply
change the policy...

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

The benefit is, that everybody can simply understand what's going on.
As far as I can see, most people use sysinit-rc by simply running
update-rc.d with the default argument, hoping that everything will
work without problems. Nearly nobody seems to know what this really
means. r2d2 with it's simple runlevel.conf configuration file makes
everything much easier. You can see with only one look, which daemons
are running in which runlevel and you can see without problems in
which order the daemons are started. They are stopped in the reverse
order which seems to be the intuitive way.

I think that Debian introduced some interesting new ideas to the
system administration, which make life easier. So I don't see, why we
should stay on old ideas here, where better solutions are possible.

> > 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 prefer to file a bug against policy ;-)

Ciao

        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: