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

[Guy Harris]

> Problems 1, 2)

>   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.

The only way I know of to interrupt an "automatic" boot to multi-user mode
is what you have on 4.xBSD and systems influenced by them.  Those systems
had a special "preen" mode added to "fsck"; this "fsck" would automatically
fix all problems which were considered by its author to be "safe" to fix
automatically, and would not fix any others.  Its exit status would indicate
whether it found problems it didn't want to fix.  "/etc/rc" would run "fsck"
in "preen" mode, attaching it to the console so that an interrupt would
abort it.  Unless it exited with a status indicating it completed
successfully, "/etc/rc" would in turn exit with a non-zero exit status and
"init" would see this and not go multi-user.  In straight V7, "/etc/rc"
wasn't attached to the console so it wouldn't be interruptable.

S5 isn't really set up to automatically go multi-user.  For one thing, it
dutifully records in "/etc/utmp" the fact that it's running "/etc/brc"
(which is what's normally run by a "bootwait" item) *BEFORE* it checks the
file systems.  Whichever genius committed this act should be sentenced to
eternity in hell repairing file systems with "db" (sic).  For another, it
has no "fsck -p" notion; you either run with everything done automatically
or nothing done automatically.  Furthermore, it has no way of aborting an
attempt to go multi-user if the "fsck" fails.

We fixed this at CCI.  I added a "bootcheck" "inittab" item; this item is
NOT recorded in /etc/utmp.  It is run before it really decides to go
multi-user; if it returns a non-zero exit status, the system goes
single-user instead.  (If you fix the file systems manually and exit from
the single-user shell, the S5 "init" will then proceed to go multi-user into
the "initdefault" state - this is a standard part of S5 "init", so you don't
have to screw around with "telinit N".)  The system we were running was
4.2BSD-based, so we already had "fsck -p".  It also handled the VAX-style
boot flags; if "init" saw that the system was booted single-user, it
wouldn't run "bootcheck" and would immediately go single-user.  If you then
exited the single-user shell, it would proceed to go multi-user without
"fsck"ing; this may or may not be the right thing to do, but it was the way
4.xBSD did it.

This is all relatively straightforward to add to "init".  Adding "fsck -p"
is best done by merging the 4.1BSD "fsck" with the S5R2 "fsck" (since both
their file systems are basically the V7 file system); you get, for free, a
multi-drive "fsck" which is reasonable, as opposed to the "dfsck" crock
which assumes that nobody *ever* has more than two spindles on a machine...
(Chris Torek's "preen" is even better, as it runs the checks on each spindle
independently, as opposed to checking a bank of partitions in parallel
4.xBSD-style which may hold up small partitions behind their bigger
partners.)

> Problems 3, 4)

At CCI we used "/etc/bcheckrc" (run by the new "bootcheck" entries, rather
than by a "bootwait" entry as in vanilla S5R2) to check file systems.
"/etc/brc" was still run by a "bootwait" entry", but all the stuff that
vanilla S5R2 does in "/etc/rc" for going multi-user was moved to "/etc/brc".
There was very little left in "/etc/rc", since changes from one "multi-user"
state to another weren't very common or interesting.  We never did this, but
we could have set up state 1 as a "multi-user" state with "multi" meaning
"one or fewer"; dumps, etc. would be done in this state, so you don't have
to go completely single-user.  (Note that the "boot" and "bootwait" stuff is
only executed the *very first* time you come up - going single-user and
multi-user again won't trigger them.)

> Problem 5) 

This calls into question the entire utility of this "syscon" and "systty"
stuff.  First of all, "/dev/console" is still an official part of the
system; how is this different from "/dev/systty" (or are they always just
two names for the same device)?  Second of all, if "ioctl.syscon" gets
smashed somehow, and "/dev/syscon" isn't linked to "/dev/systty" but to some
TTY port which does *not* come up in a usable state when it's first opened,
you are (to quote some old UNIX document) well and truly up the creek - if
it opens the port at 134.4 baud, good luck in trying to get anything done.