Re: /etc/init.d structure [long rant]
On Thu, 14 Aug 1997, Richard G. Roberto wrote:
> On Thu, 14 Aug 1997, Donovan Baarda wrote:
> > So excuse me if I have got this wrong, but does that mean going from run
> > level 2 to run level 7 requires running all K* then S* in run level 3,
> > then all K* then S* in run level 4, then all K* then S* in run level 5,
> > ..... all the way up to run level 7? And going from run level 4 down to 2
> > does the same in reverse?
>
> No. The incremental behavior is only up to the default run
> level. If there is none defined, you get prompted at
> startup for a run level and I'm not sure if the system
> should use the incremental method or jump right to it at
> that point.
>
There seems to be confusion as to how this works. I have received two
different answers from people about how this works;
1) The incremental behavior only applies up to the default run level. From
there, changing run levels only runs the K* then S* scripts for the run
level changed to.
2) The incremental behavior applies for all run levels and changes of run
level. However, "*Nothing* has an S* in more than one level. A package is
meant to be at a certain run level and higher. A level 3 package is
started at run level 3, killed in run level 2, and at *no* other level."
[Manjo]
Method 1 allows arbitary definitions of runlevels for different purposes,
allowing any runlevel to have any packages running independant of what is
running in any other runlevel *except up to the default runlevel*.
For this to work properly for all runlevel transitions, every runlevel
must have K* scripts for all packages you don't want running at that
level, and S*scripts for all packages you do want running. This has the
problem of potentialy running S*'s for packages already running, and K*'s
for packages not running. It also begs the question; why bother with
incremental running at all?
Method 2 requires a strict heirachy of runlevels, with increasing numbers
of packages and functionality as you go up runlevels. It ensures that S*
and K* are never run "out of order".
However, the strict heirachy has pretty severe limitations. It is not
possible to stop packages as you go up runlevels, or start them as you go
down. This seems to contradict having runlevel 5 as "powerdown" and 6 as
"reboot" (also, the incremental behavior would make it impossible to
"reboot" without "powerdown"ing first).
As someone else also pointed out, a clean heirachy of runlevels with
increasing functionality as you go up is not necisarily that simple. Which
is a higher runlevel, an x-terminal or a web server? Do you want xdm
running on your web server or apachie on your x-terminal?
> You only have K* scripts if you need to shut a process or
> server down for proper operation in the new run level (or
> make sure something's not running). You only have S*
> scripts for the stuff you need started _for that run level_.
>
If you cock this up, you can end up having a totaly different
configuration at runlevel 4 if you go to it from runlevel 2, or runlevel
3. Messy.
> Run level 5 isn't implemented as "power down" yet, but it
> should be. Obviously if you do an init 5, you should expect
> to go down. If you set your default run level to 7, you're
> in for a very short session ;) The 7, 8, & 9 run levels are
> unique to linux AFAIK. They shouldn't be used as defaults
> for the reason's you point out.
>
If the behavior is always incremental, then having runlevel 5 as powerdown
would make it impossible to go to runlevel 6 (shutdown).
> >
> > What I thought would be more sensible is to know what needs to be running
> > at each runlevel, and when you change runlevels, do a "diff" on the two
> > runlevels, kill everything in the first but not in the second, and start
> > everything in the second not in the first. This allows you to transition
> > faster between arbitary runlevels, and avoids transitioning through
> > runlevels you don't want to touch on the way.
>
This is compatible with the "state" model, is simple to implement, and
allows more flexibility than a "stack of states" as suggested by someone.
Note that the "stack of states" approach is similar to method 2 above, but
it could allow packages to be K*'ed on going up a level. This is more
flexible than only adding packages as you go up, but it still requires
you to step through each state in order. This means going through
"powerdown" on the way to "reboot", and possibly toggling packages on and
off as you go.
The "diff" method allows arbitary state transitions, without having to
explicity define all the actions to perform on every possible state
transition. Each runlevel defines a state, listing all the packages that
must be running at that level. The actions to perform on transitioning
from one state to another are determined by comparing the two states. Only
the minimum number of actions required are performed on any state
transition, and undesirable states can be "skipped".
> Again, changing run levels after the default has been
> reached just runs the K* then S* scripts for that run level.
> We do that part right already. We just don't define the run
> levels correctly. Until we do, its pointless to consider a
> functional rc script since the run levels will be identicle.
>
Defining default definitions for the different runlevels is a good idea.
However, we also need to know how it works. If we come up with default
runlevels that cannot be implemented using the "industry standard", then
we will be comitted to inventing our own method.
> >
> > This sort of scheme can be implemented in a variety of ways, including
> > config files, or S* symlinks in rcn.d directorys (no need for K* anymore).
> > I don't want to introduce yet another way of doing it, but it just seems
> > to make more sense to me.
>
> Well, if I run something in run level 3 that conflicts with
> something in run level 4, I need to stop the service in
> conflict before the run level 4 process tries to start.
> That's why I can define K* scripts. This works like the
> "diff" you mentioned.
>
Yeah, this para should be read in conjunction with the "diff" method. It
suggests a way that the "diff" method might be implemented using the
existing rcn.d and symlinks. You "diff" the two runlevel rcn.d directorys
(containing only S*'s), kill as required by running the removed S*'s
with "stop" parameters (in reverse order of priority), and start all the
added S*'s with "start" parameters. That's why you don't need K*'s any
more, but for compatability you could leave them there and just ignore
them. This doesn't allow you to have different K and S scripts for a
package, but I don't belive anything does that anyway.
However, before I suggest inventing a new way of doing things (too late
:-), we need to look at existing "standards" to see if they are good
enough. Can anyone clearly explain what the existing "standard" is and
exactly how it works?
ABO
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: