Subject: Summary of /etc/rc*

From: "L. Todd Masco" <[email-masked]>

I've gotten mail from some folks who aren't familiar with the SVR4
run levels, and asked me to summarize what I'm working on doing.

The concept of run levels is this: that a machine can have a
number of modes that are clearly definable.   There's the
bare-minimum (ie, "standalone"), there's behaving as a client,
there's behaving as a server, and there's up for full login.

With each of these levels, there are a well defined set of daemons
that you want to be running: for example, in server-mode you want
to be running Kerberos, nfsd, etc.

The idea is that instead of having one mammoth script run when you
go from single-user to multiple user, you have a set of scripts that
correspond to each run level.  For example, for run level 3, there
are scripts in /etc/rc.3 that start and stop each service.  Usually,
there's one script for service, so that starting an NFS server would
be something like running:

	/etc/rc.3/S10nfs.daemon start

And stopping it would be:

	/etc/rc.3/K10nfs.daemon stop

The "S" is for the script that starts the service and the "K" for
the script that stops it, but they're usually links to the same
script that checks the argument.

The number following the "S" or "K" is the relative priority of
the script in that directory: they get run in order, from S00
to S99 when entering a level and from K99 down to K00 when
exiting a level (as I am implementing it).

This allows you to have two granularities for services: you can start
and stop them individually, or you can have them automatically run
when you go from one run level to another.  If you're in run level
1 and want to go to run level 4, all the startup scripts,
/etc/rc.2/S*,  /etc/rc.3/S*,  /etc/rc.4/S* are run with the argument
"start", while going from 4 to 1 would run /etc/rc.4/K*, /etc/rc.3/K*,
and /etc/rc.2/K* with the argument "stop".

What does this get you?  A number of things:

	- First, no single rc.local script.  This means that automatic
	installation of software (or your own modifications) can be done
	merely by dropping two scripts into the directory for the
	appropriate run level.  No ugly grepping of /etc/rc.local to	
	see whether it's already been installed, and no confusion
	about what the damned installation process just did: 

	- You don't add scripts to the standalone levels, so if you screw
	something up, you can just come up to the level below what you've
	entered, remove it, and then finish bring it up.  You can do this
	in a cruder way with standalone as is, but it makes you take
	an "all or nothing" approach.

	- If you want to bring a machine up as a client but not a server
	(useful in working on some network problems), all you need to
	do is specify the appropriate run-level.  Otherwise, you'd
	either boot a machine standalone and start everything but the
	server functions by hand, or you'll boot to multiuser and kill
	each deamon by hand.  Not fun.

What I'm doing to implement it is this:

First, I'm breaking up the /etc/rc, /etc/rc.local, and /etc/netstart scripts
into their component pieces, and putting them in directories corresponding
to the run-level I think is appropriate.  This is, of course, open to
debate: I just want to get the mechanism working.

Then, I'm putting scripts in /sbin that run each level as appropriate, and
putting a script in /etc/rc that just calls each of those scripts.

That's what I'll release immediately: no large change in functionality,
though you will be able to manually go from one run level to another
by calling /sbin/rc(whatever).  So far, so simple.

The next step is to change how inittab works, specifically adding the
idea of a run-level to anything started from the run-level.  This'll
require changing init to have the concept of the run-level, which should
add about couple hundred bytes of code & storage.

And that should be it!

Comments from folks?   I fail to see what the objection is.
--
L. Todd Masco  | "Hide, witch, hide!  The good folk come to burn thee, their
[email-masked]  |  keen enjoyment hid behind a gothic mask of duty." -JS/BATE

---

From: Charles Ewen MacMillan <[email-masked]>

On Mon, 12 Sep 1994, L. Todd Masco wrote:

> Date: Mon, 12 Sep 1994 18:07:38 -0400
> From: L. Todd Masco <[email-masked]>
> To: [email-masked]
> Subject: Summary of /etc/rc*
> 
> 

 <deletia>

> 	/etc/rc.3/K10nfs.daemon stop

 Although the stop argument feature might be useful for a few daemons
(I cannot see nfs being one of them however, as the drives must be umounted
from the clients), I fail to see why the current state of affairs should
require _one_mammoth_script_ when individual scripts can be intr'd from
rc.local as is.

> 	each deamon by hand.  Not fun.

 Or, alternately, you can leave a single flag and "if" statement at the 
beginning of /etc/rc.local to boot whatever daemons you please, without
any changes to the current implementation.

> Comments from folks?   I fail to see what the objection is.

 The way my systems are setup, is that rc.local launches some daemons 
which always run (i.e. fakerwhod) and shells out to other scripts to 
launch subsystems which require a more complex startup (i.e. bind, news).

 Most other daemons are launched directly from inetd. Even on my main 
server system (a Sun) there are only 17 daemons (counting portmap and 
keyserv as daemons) as I count it launched from either /etc/rc or 
/etc/rc.local. Of those 17, 10 of them _must_ running when the system
is using any kind of networking, 3 are run from their own seperate scripts
and 1 I could do away with. 
 
 This says to me, that I could place on my most complex machine, 3
launched processes in an intermediate script between single user mode
and multi-user startup.

 On the BSD machines, there is less to run than on a Sun, so it seems
to me there would be even less use for the setup you are describing, and
in my opinion, not nearly enough usage to warrant the changes to
init, changes to existing startup scripts, and more importantly drift 
from the rest of m68k.

Charles Ewen MacMillan  | Tezcat.COM - Wicker Park 
  <[email-masked]>    | Offering Internet Access 
Modem: 312-850-0112/0117| Via Interactive UNIX to 
Voice: 312-850-0181     |    the Chicago Area.
WWW: http://tezcat.com/ | Mail: [email-masked]

---

From: [email-masked] (L. Todd Masco)

(Sorry, something I forgot to address)

In article <Pine.SUN.3.90.940912184822.19817C-100000@xochi>,
Charles Ewen MacMillan <[email-masked]> wrote:
>from the clients)

If you meant from the server end: NFS is stateless, so as long as the
clients are not actively using the drives, they should be fine.  If
you meant from the clients, then that's the sort of thing that you
would put into the NFS shutdown script: umount and then kill the
daemon.
-- 
L. Todd Masco  | "Hide, witch, hide!  The good folk come to burn thee, their
[email-masked]  |  keen enjoyment hid behind a gothic mask of duty." -JS/BATE

---

From: Charles Ewen MacMillan <[email-masked]>

On Mon, 12 Sep 1994, L. Todd Masco wrote:

> Date: Mon, 12 Sep 1994 21:05:35 -0400
> Subject: Re: Summary of /etc/rc*
> 
> 
> Charles Ewen MacMillan writes:
> Ah, but that *is* a change to the current implementation.
> 

 Yes, but it is a site-specific change, rather than a change to NetBSD
 source tree.

 I change many things on my own machines, to make them more compatible
 with the Suns, Macintoshes, etc.. that they must run with, that I would
 never suggest implementing as standard features.

> Maybe you missed it the first two times I said it:

> change in only the Amiga NetBSD.  I'll makw this available through the
> Amiga list, people can test it, and then I'll propose it back to
> everyone for *all* of NetBSD.  If it isn't taken up, then I'll
> distribute is as a patch to NetBSD in general.  IE, I'm not developing
> this just for the Amiga: I want to be able to use it on our VAXen when
> NetBSD is stable for them (You can't complain about bad UNIX
> implementations until you've administered Ultrix machines).
> 
> The changes to init are trivial -- and what you're saying is that we're
> better off with everyone making their own independent changes to
> startup scripts in incompatible ways.  Obviously, I strongly disagree.

 So far, you have:

1) Stated that my arguments were probably "religious" in nature, without 
   apparently, bothering to look at the justifications for those arguments.

2) Stated erroneously, against my protestations, that they were in fact
   "religious" in nature, thereby implying that the arguments could not
    bear any weight.

3) Implied that I do not know how to administer a site, due to a lack
   of knowledge admitted on my part, of who collaborated on SVr4, in
   a further attempt to invalidate my argument.

4) In the end, having bothered to read at least a few lines of what I
   was saying, summarized the argument as stating that we are all:
   "better off with everyone making their own independent changes to"
   "startup scripts in incompatible ways." I fail to see what is 
   incompatible about my implementation of these startup scripts, as
   after all, I have kept these very same scripts through several 
   upgrades.

   I could run any rc.local file that I have, on any machine in use
   on this site, which is I think a far greater compatibility than otherwise.

> 
> It's great that your own setup on your machines is so simple,
> that you never need to bring a machine partially up, and run no
> product- and other- related add-on startup scripts and daemons
> that you might want to modify in a system-safe manner.

 I clearly do run product related scripts, as stated in the previous 
posting. Doing so does not require init levels in any wise.

 Running them in a "system-safe" manner requires making them 
interruptable, which is already available in current.

> Not all of us have such simple setup.  A machine with flexfax, INN,
> named, and framemaker (for example) will have a family of things
> to run for each setup.  Any time you modify the scripts with each
> of these, you can screw your entire rc.local -- with run-levels,
> you'll only screw up the immediate family of daemons.
>

 Obviously, as I mentioned named and "news" explicitly in my next to 
previous posting, I am running both of these daemons, I said "news" for 
those less familiar with INND.

 Both daemons keep track of their own PID's in file format, hence neither 
requires more than three lines (counting the test to check for their 
existence) in any given rc script, and in the case of my system, they 
have seperate rc's which are run "intr."

 This pretty much prevents them from "screwing up any rc's."

 My system setup could hardly be called simple, it is simply efficient.

> I don't think it's good design to avoid a scalable startup system
> just because the base system isn't that complex (right now).
> --

 What is ever likely to be added to the base system, on a global level 
that is going to _require_ a scalable startup? Not likely anything.

 There are many things that should be implemented at _user_ or _site_ 
level that people apparently wish to be added into the operating system.

 Perhaps I will start arguing that everyone adopt my libc changes so 
that I need not rebuild it with each complete overhaul.... har.

---

From: Charles Ewen MacMillan <[email-masked]>

On 12 Sep 1994, L. Todd Masco wrote:

> Date: 12 Sep 1994 22:20:26 -0400
> To: [email-masked]

 In the first place, I know of very few sites that export drives to 
client machines that are not going to be used.

 In the second, client case, if the drives are mounted hard, then one is 
unlikely to be able to umount them successfully from a script. Important 
drives (i.e. drives that are used continually, or neccessary to machine 
operation) are likely to be mounted hard.

 The script in short accomplishes no more than attempting to umount the 
drives, and then killing the process.

 This can be done, again, without init_level support or seperate rc scripts.

---

From: Karl Ivar Dahl <[email-masked]>

I have been following this thread for some time now, and
feel I must express my views.

First of all, I am no expert at all on the area, and that is
my main reason for replying.

If I have understood the "inits" of L. Todd Masco correctly,
he proposes a rc setup that can (remotely) be compared
to the Amiga's startup-sequence and user-startup.

Well, nobody can say splitting the startup-sequence in two
was a bad idea??
I am going to install Unix at home to allow me do some
schoolwork. I do not have the time to become an expert.
Therefore, the separation of programs and system scripts
sound an excellent idea to me. That way, I can update my init
scripts without having to know what I am doing :) I can even
uninstall programs by deleting their corresponding scripts.

What I am saying here, is that new users can copy the setup
of a friend, or edit a given line-number, without
understanding the rest.

I do not know hox Linux does it, but I do know many Linux users
that don't have the faintest idea how the system works. Linux
has somehow appealed to a broad userbase, and that is its
real strength. I feel that is the way to go for NetBSD too.

Those that complain about this new setup seem to be 
perfectly able to edit their own rc, so what's the problem??

You could always go on and say that NetBSD if a research project,
and never meant for newbies. You do that, and I will wait
for Linux. And I don't think I'm the only one.

Call me a religious newbie or whatever, (apparently the new in-word :^)

Karl Ivar Dahl

---

From: Karl Ivar Dahl <[email-masked]>

L. Todd Masco writes:
 > > that don't have the faintest idea how the system works.

>Linux uses run levels -- but to be fair, I doubt that it's the modularity
>that run-levels bring that causes Linux to have such a wide appeal.

I agree, but it is not what I (tried) to say.
I meant that the *lack* of run-levels might become one of the reasons
NetBSD *won't* get such a wide appeal, not that run-levels made
Linux popular :)

Now, listen carefully: I didn't say NetBSD won't be popular.

Nah, It's not that good an argument anyway. I suppose I will
have to live with NetBSD no matter how greek the rc is. :)   

Cheers,
Karl Ivar Dahl

---

From: Hubert Feyrer <[email-masked]>

> are scripts in /etc/rc.3 that start and stop each service.  Usually,
                      ^^^^
I'd stick rather closely to SVR4 (or Solaris, if that matters),
marking directories which contains scripts with a ".d"-suffix. I.e.
naming the startup-scrupt for multiuser/server-mode "rc3", but putting
the init-scripts for it into "rc3.d".

Also, putting all the startup-scripts into "/etc/init.d" and linking
them into "/etc/rc?.d" sounds nice to me, as I now where to look if I
want to change a single startup-script.

Hubert

=============== Hubert Feyrer ============================================
      Weekdays: Rennerstr. 19, D-93053 Regensburg,  Tel. 0941/701788
      Weekends: Bachstr. 40,   D-84066 Mallersdorf, Tel. 08772/6084
      Internet: [email-masked] == IRC: hubertf
==========================================================================

---

From: [email-masked] (Rob Healey)

> want to change a single startup-script.
	I second the motion. Being able to install the script in /etc/init.d
	and then link it to it's S and K files makes life ALOT easier
	when searching for what script does what; just grep in /etc/init.d
	rather than all the /etc/rc?.d directorys.

		-Rob

---

From: Charles Ewen MacMillan <[email-masked]>

On Tue, 13 Sep 1994, Karl Ivar Dahl wrote:

> Date: Tue, 13 Sep 1994 09:31:10 +0200
> From: Karl Ivar Dahl <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]

 There are on the other hand people who dislike run-levels as an idea.

 If and when they are added, I doubt that very many people will be using 
them. 
 
> have to live with NetBSD no matter how greek the rc is. :)   

 It is not "greek" in its current state, it is simply more typical of the 
Berkeley style Unices than SVr4 Unices.

---

From: Charles Ewen MacMillan <[email-masked]>

On Tue, 13 Sep 1994, Karl Ivar Dahl wrote:

> Date: Tue, 13 Sep 1994 09:09:49 +0200
> To: [email-masked]
> Cc: [email-masked], [email-masked]

 I am afraid this is not the case. In the first instance, the "startup" 
on a NetBSD system, as it comes from the base installation is split up 
into more than one section, and in fact, can be split-up infinitely if 
one wishes to so do, i.e.:
--------------------------------------------
 touch /

  [ $? -ne 0 ] && . /etc/rc.single
  "Remounted root....."
 fi
 ...  < things following remount ommitted >

if  [ ! -f /etc/multi-user-mode ]; then

     [ ! -f /etc/no-net ]  && . /etc/rc.local
      "Started Network Daemons......" 
     fi

     [ ! -f /etc/no-daemons ] && . /etc/rc.news
      "Started INN...."
     fi
fi
 ---------------------------------------

 With an /etc/rc like the above, the following line would take the system
 down, and restart all system tasks save for INN startup, and anything
 else on INN's rc script.

  echo "" > /etc/no-daemons ; kill 1

 What is instead being proposed, is changes to the program /sbin/init 
which is one of the lowest levels of the UNIX operating system, and which 
runs continually from power-on and boot-up.

> uninstall programs by deleting their corresponding scripts.

 All of the above are possible with the current setup however, as is 
shown in my example. Installation and de-installation of programs has 
little to do with /etc/rc.* unless the program needs to be installed in 
the system startup, which applies only to daemon processes.

> perfectly able to edit their own rc, so what's the problem??

 I am perfectly able to edit my own rc, however, these are not just 
changes to the rc files, they are the addition of a new system of 
understanding them to the program init.

---

From: [email-masked]

Hi folks;  just my two-pennorth, not intended as a flame or slight on anyone's
opinions in any way <grin>

 > require _one_mammoth_script_ when individual scripts can be intr'd from

I just wanted to relay my experiences;  I am not mangler of a vast multi-machine
system running huge numbers of daemons, just a single-machiner...  But I have
been involved in writing an introductory document/FAQ to detail how people at
my university can connect to the college computers via SLIP & a phone.

The document covers NetBSD, Linux and AmiTCP users.  As a NetBSD'er, the Linux
coverage was my first real encounter with fiddling with run levels and the like.
Initially I kinda figured it was a kludge designed to make things complicated
<grin>, but experience tells me it can me very handy, particularly when dealing
with beginners (and lets face it, a lot of _any_ free package's users are going
to be beginners dabbling because theres nothing to lose).

Particularly, "automating" the network installation is a deal less scary in the
Linux system if something goes wrong;  because the networking changes etc. can
all go in the MultiUser runlevel scripts, a cockup is pretty simple to fix
just by booting into single-user mode & fiddling a bit :*)  This means a user
with minimal competence has to make a real effort to make the system completely
unusable - a real boon :*).

 > any changes to the current implementation.

Surely tho, that is a local change to the implementation?  If you don't
disapprove of this, surely if the multiple-run-level init patches were 
distributed as an optional extra, would that be acceptable?

The only problem with this, of course, is that install scripts provided with
additional packages would assume a standard setup I guess /-|.  Hmmm.
Still, thats the nature of compromise I 'spose <grin>

 > init, changes to existing startup scripts, and more importantly drift 

Does it have to result in a drift?  I (personally) see no reason why the
changes couldn't be fed back into the general tree if they were regarded as
beneficial.

 > Charles Ewen MacMillan  | Tezcat.COM - Wicker Park 

Cheers;
Cheers;
-- 
 __ //||/  Tim Walls/TJay            EMail                 [email-masked]
 /_//=|/  My opinions are my own    PGP2.3 Key, finger  [email-masked]
----------------------------------------------------------------------------
  `And with the last line almost drawn, wish you goodbye 'till further on'