[H-GEN] Boot Up sequence

[The memory remains]

On Fri, 26 Sep 1997, Geoffrey D. Bennett wrote:

> This isn't correct.  An absent link indicates "no change" for that
> service.  It is not undefined.  Red Hat's tksysv runlevel editor
> thinks it's an okay thing to do too.

	There are things we could say about redhat at this point.  What 
this does is force your init setup to have a BSDish memory effect, where 
old services from previous runlevels come back to haunt you.  In this 
setup you cannot be sure as to exactly which services are running in any 
particular runlevel.

	It's more of a religous point than a practical one, but then I'm 
more of a Zealot then most.  Instead of drinking blood and silently 
moving on murder sprees, I direct my energies into making sure things are 
perfect, or at least tell people how to make them perfect.

> What about the "halt", "single", and "reboot" services that are
> started in init states 0, 1, and 6 respectively?  Are you proposing to
> add "K" links for them in states 2, 3, and 5?

	Those particular scripts are hacks.  Unix is not designed to go 
down... at the last minute, a rouge design team got together and someone 
said "How did we go about starting this thing up again?".  The same 
thing happened late in the design phase of my CS382 project <"I really am 
serious" look>.

	How would I do it?  Well personally I have a script called unix 
or something similar which did both starting and stopping.  An S link 
would do normal boot.  A K link would halt or reboot the machine
(default halt, but sysadmin tinkerable).  That takes care of booting and 
shutting down normally.  The seperate reboot runlevel is a major hack, 
and should never have caught on.  Firstly it reduces the number of 
available runlevels sensibly to 4, a foolishly low number for sys V init 
purposes (yes I know that some inits will allow runlevels > 6, but that 
just raised the hack another order of magnitude).  The reason they did it 
that way is that there is no clear way to communicate with these scripts 
except through runlevel changes, or filesystem changes.  Both of those 
are hacks...

   <fuzzy goes to sit in a corner for a while with a can of baked beans...
      ... but can't get to the pantry without disturbing the sqatters>

	There is a clear need for a seperate shutdown procedure for halts 
and reboots.  A remote user may need to bring a machine down and 
immediately back up to change kernels or the like (I won't mention other 
less holy reasons for rebooting a machine).  Halt of course can't be 
overlooked, because it's just too emotionally draining to cut the power 
in the middle of a reboot.  This is a realm where compromise insideously 
breeds.

	What we need is a better way to communicate with init scripts.  
One possible solution is to allow init to pass on parameters to service 
scripts.  It's still dodgy, but in my opinion is decidedly less dodgy 
than having to have multiple run levels for the same final state (an 
inactive machine).

	What, you ask of single?  Single is another hack.  It's a hack 
that means only minimal services should be operating.  Anything that 
needs to be killed when entering single user mode is big enough to be 
considered a service anyway.  The main use of single user mode is to kill 
off all the users on a machine.  This could be described as a service 
that when started spawns the appropriate gettys and when stopped kills 
off any users not in a special file (which would include root, and a few 
other obvious ones).

	The final thing I would like to change about init, is that 
services are not automatically restarted.  Any service should be treated 
in the same way as a getty, and handled directly by init.  To make this 
feasable there should be an idle shell command which will send any 
processes that only need to perform their actions once into an indefinate 
wait.  There should also be a mechanism available to pass control over 
particular processes back to init.

	Remind me in a month and a half, and I'll see if I can get a 
working version of this init into action <smile>

> If someone wants to completely prevent a service being started in any
> runlevel, they need to remove all the "S" links in the rc?.d
> directories.  They should also remove all the "K" links because if the
> service is never started it will never need to be stopped.  There is
> no point having "K" links in all the rc?.d directories.

	I am diametrically opposed to the idea of starting and stopping 
things in relation to the S and K links.  I see them as a service on or 
off.  Why aren't they labelled that way?  Well, O and O is a little 
ambigous don't you think?


> OTOH, if someone wants to have a service that is started in one 
> runlevel but not another then they should do what you suggested 
> (change the "S" link to a "K" link), otherwise if they switch 
> runlevels after boot-time, the service won't be stopped. 

> It all depends on whether you don't want the service running in a 
> particular runlevel or whether you don't want the service running at 
> all (and it was the latter which I think the original question was
> about).

	There is no point in making this a special case.
	Say there is only one runlevel where a service is required to be
active.  There are many K links, and only one S link.  For any two runlevels
with K links, it is killed without ever being started.  This is normal
behavior, and should not change simply because the final S link is removed.

        The memory remains <memory at techie.com>
        (with a swag of input from fuzzy)

            ///      ///  ///  ///            ///   ///
           /// ///  ///  ///   ///  ///  ///      ///
          ///            //   ///               ///
         /// ///  ///       ///   ////////    ///
        ///      ///    /////               ///

        Web page at http://student.uq.edu.au/~s335810

----------------------- HUMBUG General List --------------------------------
echo "unsubscribe general" | mail majordomo at humbug.org.au # To Unsubscribe