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 [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .