> When thinking about the general sysV init concept I now find it quite > strange that I have to add kill scripts to the "new" runlevel. > Wouldn't it be more logical to add kill scripts to to "old" runlevel > and then run the start scripts from the "new" runlevel? Usually I know > exactly what I'm starting in a runlevel, and I should take care of > exactly that collection of services when I "leave" that runlevel, > shouldn't I?
I thought so too, so I rewrote all the init scripts, still within the SysV paradigm. This is from the README: In many common versions of SysVinit the runlevel directories are setup with the idea that they kill anything that might be running which they don't want, before starting what they want to run. Each runlevel is expected to know more than it should about all previous runlevels. The problem for scripts is "might be running". Depending on the runlevels involved, they can't be sure if they're being asked to kill something that was never actually started, e.g. rc1 to rc0 vs rc3 to rc0. So they have to set "lock files" or something as notes to themselves if they started anything. It's esthetically unpleasant. [I hate chkconfig!] In this version the idea is, "You started it, you kill it." Processing within a runlevel starts by starting processes, not killing them. In setting up most runlevel directories one creates the S-links for tasks to run at this runlevel, and instead of placing the corresponding K-link in up to 6 different directories, it goes in this same runlevel directory. That makes setting up the rc*.d directories MUCH simpler and less error prone. One should only have to think about killing what is still running in this runlevel. In the previous example, rc1 stops what it started, rc3 stops what it started, rc0 gets the same system state. Knowledge of what's running is implicit in what the runlevel has started. The individual scripts are simpler. They don't need to "remember" that they started a daemon so they can check later whether there is one to be stopped, or not. When they are called on to stop a daemon, they can safely assume that they started it. "Entering runlevel N, I start the daemon. Leaving runlevel N, I stop it." "rc" is is the runlevel change script. It's responsible for starting processes when entering a runlevel, and stopping them when leaving. Its processing was simplified by functionalizing those tasks. Of course, this control script will look ahead and avoid calling scripts to stop something when it's to be started in the new level, and similarly avoid restarting it again. Thus daemons can continue through a runlevel change, and will be "adopted" by the new runlevel as if they had been started by it. "sysinit" is the primary initialization script called in inittab. It just starts every S-link in rcsysinit.d in order. It's very uncomplicated. (The corresponding K-links are put in the rc0.d & rc6.d directories as needed, not rcsysinit.d.) "shutdown" should be the only script started by rc in runlevels 0 & 6. It's job is simply to stop the fundamental processes started by sysinit, and left running through all runlevel changes. It will stop all K-links in those runlevel directories. Depending on how one looks at it, this may or may not seem like a wrinkle in the paradigm defined above. Where there was one script, there are now three. Both sysinit & shutdown are very much simplified versions of rc. And this design has simplified rc in turn. The one script had logic and exceptions for special processing. The three new scripts are nearly "straight-line code", basically with one job to do. Task scripts should find their job easier, less checking to figure out if there's really something to stop. Pseudo-code followed. -- Paul Rogers [email protected] Rogers' Second Law: "Everything you do communicates." (I do not personally endorse any additions after this line. TANSTAAFL :-) -- http://www.fastmail.com - The professional email service -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
