Subject: Re: /etc/inittab (was: /etc/default)
To: Captech) <greywolf@tomcat.VAS.viewlogic.com (James Graham>
From: Leo Bicknell <bicknell@ufp.org>
List: current-users
Date: 07/30/1995 14:48:57
> I think the general consensus has been trying to find a way around this.
> How many "run levels" do you _need_?  I can only think of four:
> 
> 	halted
> 	single-user
> 	multi-user standalone
> 	multi-user networked (or, as I put it earlier, "multi-user with
> 		a side of bacon")
> 
> The last two may seem redundant but if you have a machine you're migrating
> on and off the network, it might be nice to have a mechanism in place to
> facilitate this.  Since we're all resourceful hackers to some extent,
> everyone will probably come up with their own way of doing things.

	Let me describe the "system states" as they exist now, and
let people add what exact functionality is missing now that is really
needed.  I'm still not seeing the argument to switch to all this run level
stuff.

1) Halted.  I think everyone agrees here.

2) Single-user, or, more correctly "maintance" mode.  Only the absolute
   essentials are running (ie the kernel) and nothing has been done to
   the rest of the system to allow people to attempt to fix trashed file
   systems et all in a pretty clean enviornment.

3a) Multiuser, but without the users.  In particular "touch /etc/nologin".
    Very useful for maintance you want to do with the whole machine up
    (ie so you can log on via X) but don't want users on because something
    they need is missing (ie, their home directory) or because you don't
    want them slowing down the system.  In this mode you have full networking
    and all so the administrator can communicate with other machines.

3b) Fully up and running, multiuser.


	Now, it seems to me most people feel the "need" for a "2b"
state.  A single user state with networking enabled.  I have to ask what
is wrong with the 3a state for that.  The first argument might be there
are things like web servers and ftp servers running in 3a that might 
not be running in a "2b" state, but for 99.9% of the maintance 
does that matter?  I'd venture to most people it doesn't, at least it
normally doesn't in my work.


	Now, that's the run level argument.  To summarize, I think what we 
have now is right, halted, single-user, and multi-user.  There is another
argument at work here, the multiple start up scrips vrs a single startup
script.

	I'll admit it is nice to be able to start and stop individual
programs via "init.d" scripts.  I don't see why this needs to cause
a large change in the way things are done now.  It would be rather
simple to have /etc/rc run everything in /etc/rc.system/ and then
everything in /etc/rc.local/ for instance.  The scripts in those
directories could be used to start and stop individual things, if need
be.

	Moreover, if you buy my run level argument above it makes
the whole transition between run levels thing a lot simpler.  To go
from single user to multi-user you run /etc/rc, as is done now.
To go from multi-user to single-user you kill _everything_, just like
now.


	That leads me to my recomendation:
1) Keep the current /etc/rc and /etc/rc.local in the distribution 
   for those people who like that setup.
2) Switch to an /etc/rc that runs all the scripts in a /etc/rc.d/
   directory, and then runs everything in /etc/rclocal.d/
   (which makes it easy for people to add local scripts and know 
   where to put them).  In addition, on startup /etc/rc can take
   the names of all the scripts in those two directories
   (probably named Sxxname, as they are on run level systems now)
   and make links from /etc/startup with the "name" to the rc
   directories, so the system administrator can put that directory
   in their path to start and stop everything.

Summary:
/etc/rc   # Runs things in /etc/rc.d and then /etc/rclocal.d
/etc/rc.d/S00dothis
/etc/rc.d/S41dothat      # and so on
/etc/rclocal.d/S00httpd  # etc.
/etc/startup/dothis -> ../rc.d/S00dothis
/etc/startup/httpd -> ../rclocal.d/S00httpd

	Having /etc/rc make the links in /etc/startup as it runs
things elimiates the need for the administrator/installer to worry
about where to put them and where to create the link.  All
non-system startups go in /etc/rclocal.d and get a link automagically
on the next startup.


	So I ask, does this sound like the features people want, without
the problematic features we all keep generating e-mail about?

-- 
Leo Bicknell - bicknell@ufp.org    | Make a little birdhouse
               bicknell@vt.edu     | in your soul......
               bicknell@cs.vt.edu  | They Might
http://www.ufp.org/~bicknell/      | Be Giants