Q's on: System V /etc/init....

[Mats Wichmann]

During the years (about two) I have been working with System V, 
I have had several run-ins with the init program. Many have been 
resolved by now, but I am still having some trouble getting the 
machine I have at home to do the things I want. Basically, the 
secnario I would like is the following (which I think is reasonable):

1. Bring system directly up to multi-user without operator
   intervention.
   
2. Be able to terminate the boot->multi-user sequence in some
   way, leaving the system in single-user mode (like, if the
   system was damaged so that it can't come up multi-user,
   it would be nice to be able to perform repairs...).

3. Be able to take the machine down to single-user to perform
   backups and such, and then come back up to multi-user.

4. Be able to toggle between levels in multi-user mode to
   allow different default conditions (I use init mode 2
   to enable a login on a dialin line, and init mode 3 to 
   turn it off so I can use it as a dialout) without the multi-
   user initialization sequence being executed each time.

5. Be able to insure that the hardware console port is in fact
   the virtual system console, even if I shut down from another
   terminal (consider the case when the console hangs but
   you still want to do a clean shutdown...)

I don't think these are unreasonable expectations, and these
are all things which should able to be done without access
to source code (it happens I have access, but use of it is
not authorized for my machine). Here is some of what I have found out.

Most of the work should be in setting up /etc/inittab and the
scripts it calls. The format of inittab is discussed in three places: 
manual pages init(1M) in the Administrator Reference Manual and inittab(4)
in the Programmer Reference Manual, and "Setting Up the UNIX System"
in the Administrator Guide (these refer to the AT&T SVR2 manuals).

Problems 1, 2)
  First, booting directly to multi-user: setting the "initdefault" line
  to contain a numeric level takes care of this. Incidentally, "Setting Up.."
  claims the the initdefault entry is usually single-user. Inittab(4)
  states quite conclusively "Also, the initdefault entry cannot
  specify that init start in single user mode". This latter statement
  is completely false - specifying single-user is just fine.

  However, I have not discovered a way to abort this sequence and have
  the system go into single-user mode, say by hitting delete, as used
  to be the case when I worked on V7 systems....I can also not see any 
  clean way to do this, but any hints would be appreciated.

Problems 3, 4)
  /etc/rc is usually executed when "going multi-user". If the entry
  for /etc/rc is set to be of type "bootwait", it will be executed
  upon init entering a numeric state for the first time. This is
  probably appropriate for most systems. The other approach is to
  set it to be type "wait", and to check the run-level information
  in /etc/rc itself. The prototype rc AT&T provides does this - it
  checks that the current run-level is 2, and if so does initialization
  things appropriate to starting multi-user mode. The problem with
  this is if you switch between init states 2 and 3, like I do,
  this gets awakened each time state 2 is entered. The current
  run-level is unimportant, what makes sense is to check that the
  *previous* run-level was S (single-user). Thus, instead of this :

:
# /etc/rc - multi-user initialization (AT&T sample)
set `who -r`
if [ $7 = 2 ] ; then
	go set up the world
fi

  Try this:

:
# /etc/rc - multi-user initialization (my sample)
set `who -r`
if [ $9 = S ] ; then
	go set up the world
fi

Problem 5) 
  This one has me stumped. When shutting down from a terminal, the
  system virtual console (/dev/syscon) is linked to that port.
  The following things *should* occur: tty modes from the port that
  did the shutdown are written to /etc/ioctl.syscon; these are
  then used to reopen the port in single-user mode. A message that
  there is a remote console is output on the physical console,
  and control can be regained on the physical console by typing a 
  delete. There is also a line in /etc/inittab which removes the entry 
  for /dev/syscon and links it back to the physical console
  (/dev/systty). This should be invoked at each numeric state. None 
  of this appears to work. The alternate console comes up without 
  input echo, and it does not carriage return (line feed only) 
  on output. Nothing is printed on the physical console to indicate 
  there is a remote console, and a delete on the physical console 
  certainly does not regain control. And the line in inittab does 
  not manage to relink syscon to systty - after the system comes up, 
  syscon is still linked to the port the system was shut down on.

To forestall some further questions, should anyone have 'em,
the machine is a 68000  using a descendant of the MIT compiler;
it is not a Fortune; init is identical to that distributed
with SVR2 (and R2v2, of course) except that the default line
speed is set to B9600 instead of B300 (I have at one time
diffed the source code). The console port is physically of the 
same type as the other serial ports (it is port 00 on a four-port 
board). I can of course admit to possible problems with the serial 
board driver - after all I didn't write it ( :-) ) but I can't 
really see how they could cause this - seems we are talking about
process signalling here, not driver features....

And for those who object, sorry about the length of this posting.
I obviously thought this was interesting or I wouldn't have
bothered. I think the general question relates to the usability
of System V as a commercial binary product - which AT&T is pushing
so hard - and nobody whose box I have looked at has solved these issues.
Of course, I have not seen that many, but still...

Mats Wichmann
Fortune Systems
{ihnp4,hplabs,dual}!fortune!mats