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

Re: RFPondering: runlevelconf, dependency-based init.d scheme



On Sat, May 27, 2000 at 06:19:01PM -0700, Robert Woodcock wrote:
> On Sat, May 27, 2000 at 07:38:25PM +0200, Wichert Akkerman wrote:
> > Previously Tommi Virtanen wrote:
> > > 	Hi. I recall there has been some talk about the
> > > 	ugliness of the current sequence-based init.d-scheme
> > > 	(mostly that its hard to add things in the middle of
> > > 	the sequence, between two adjacent numbers). I
> > > 	recall there was talk about a dependency-based
> > > 	scenario.
> > 
> > Talk to Richard Gooch, he was also doing something similar. I
> > punched some holes in his design and haven't heard from him
> > since though :(
> 
> I worked on something like this over a year ago, and Anthony Towns
> was able to do most of the coding on it. Nothing really ever happened with
> it though.
> 
> Please check http://master.debian.org/~rcw/BootDependancies, the code is
> also in that directory.

I am not really sure I follow these comments; in particular, I think
my runlevelconf package is a less dramatic change to the init scheme
than the above doc (no parallelism).  Also, I am not suggesting a
design but a program I have been using on my own machine.

Indeed, I am talking about a collection of 12 scripts which I believe
makes it easy to set up, maintain (view, analyze, etc), and then use
start/stop dependency trees.  

These scripts provide a complete replacement of the current sequence
based init scheme managed by /etc/init.d/rc.  You just modify
*slightly* this `rc' file to run the script called rlc-go which then
provides an appropriately ordered list of daemons to stop, and an
another list of daemons to start at the new runlevel.

If you want, you can use the scripts to "dependency" manage just a
subset of the services.

I think a dependency based start/stop scheme is much easier for a
sysadm than the present one.  

Indeed, when the sysadm has to install ypserv and ypbind, all she has
to know about them is that ypserv depends on syslog and network (say),
and ypbind depends on ypserv for running. With the runlevelconf
package, then she would enter

rlc-add 2s ypserv syslog network
rlc-add 2s ypbind ypserv 

to  add ypserv and ypbind to the start tree for runlevel 2.

As an example, to set up a small start tree for runlevel 2 from
scratch, just execute the series of commands

rlc-add 2s syslog
rlc-add 2s network
rlc-add 2s sendmail syslog
rlc-add 2s ypserv syslog network
rlc-add 2s ypbind ypserv

to get the tree

2s
|-- network
|   `-- ypserv
|       `-- ypbind
`-- syslog
    |-- sendmail
    `-- ypserv
        `-- ypbind

(Entering `rlc-add 2s ypbind ypserv network syslog' instead of
`rlc-add 2s ypbind ypserv' would result in the same tree for obvious
reasons).  

>From such a tree, it is easier to read off the real dependency of
services, but instead of straining the eye, the sysadm can run 

rlc-parlist 2s ypbind

to get

Parents of ypbind:
network
syslog
ypserv

>From the tree, it is clear that first network and syslog, then
sendmail and ypserv, then ypbind should be started.  Of course, there
is a script to make up this schedule:

rlc-doit 2s

would produce the files 

2s-schedule/1:
network
syslog

2s-schedule/2:
sendmail
ypserv

2s-schedule/3:
ypbind

So the above is the schedule to start these services during a switch
to runlevel 2.  

Now, the above steps were done in peacetime, and the above schedule is
static. When it comes to switch to runlevel 2, the schedule has to be
modified since some of the services might be already running, so they
do not have to be started.  Now the only script that communicates with
the `rc' script is rlc-go; it feeds only those services to start to
the `rc' script which are not already running.
 
More detailed description in 

ftp://moni.msci.memphis.edu/pub/run/runlevelconf.README

and in MANUAL of the tarball:

ftp://moni.msci.memphis.edu/pub/run/runlevelconf-0.05.tar.gz

Best,

Mate
---
Mate Wierdl | Dept. of Math. Sciences | University of Memphis  



Reply to: