/etc/rc, /dev/console, and the C shell

[utzoo!decvax!ucbvax!menlo70!sri-unix!ucla-vax!wales at Berkeley]

RE:  Consequences of changing "init" to make /etc/rc a C-shell file
     and give it /dev/console as its stdin/stdout/stderr

I while ago I asked for comments about the above suggestions.  I went
ahead and implemented them about a week ago.  It seems to work fine.

The first immediate benefits of doing this were that I was able to take
advantage of the C shell's nicer (in my opinion, at least) control
syntax, and I didn't need to write ">/dev/console" at the end of
practically every line.

Further, I was able to make the following nice additions to /etc/rc:

(1) We are running 4.1BSD and thus have the automatic reboot facility
    with "fsck -p".  If /etc/rc is invoked without an auto-reboot being
    indicated, I query the operator as follows (remember that "init"
    passes the argument "autoboot" to the /etc/rc shell when an auto-
    reboot is desired):

	if ($#argv == 0) then
	    echo -n ^G^G^G^GCheck file systems? ''
	    set XX = $<
	    if ($XX == yes || $XX == y || $XX == "") then
		set argv = autoboot
	    else
		echo -n ^G^G^G^GNO?? '' Are you sure?? ''
		set XX = $<
		if ($XX == yes || $XX == y || $XX == "") then
		    goto nochecks
		else
		    exit 1
		endif
	    endif
	endif

    where "nochecks" in the above is a label placed just after the
    part that invokes "fsck -p" and examines the exit status.  This
    makes it possible to go single-user, then check the disks and
    come up automatically, without having to reboot.  (How many times
    do you REALLY want to go multi-user from the single-user shell
    without running checks?  Sometimes, I agree, but not often.)

(2) I can now interrupt /etc/rc at anytime before it exits, and return
    to single-user mode, by having "onintr interrupt" near the beginning
    and the following at the end (just after the "exit 0"):

	interrupt:
	    echo ''
	    echo -n reboot interrupted: ''
	    date
	    exit 1

    Previously, if I tried to interrupt /etc/rc after "fsck" was done
    (or if "fsck" wasn't done), I succeeded only in aborting individual
    commands; /etc/rc as a whole would just keep rolling along, and the
    only way to stop the juggernaut was to do a control-P and halt the
    CPU.  (Reason:  /etc/rc had no controlling TTY, but daemons and
    such with ">/dev/console" did.)

Several people warned of problems relating to the assignment of process
groups.  I haven't had any difficulties here.  "update", "cron", and the
other daemons spun off by /etc/rc end up in a process group equal to the
PID of the shell which executed /etc/rc.  This PID is NOT the same as
that of any login shell subsequently created on /dev/console, and
"newproc" (sys/slp.c) never reuses a PID that is an active process group
ID, so my daemons can't be affected by anyone doing interrupts, quits,
or "kill 0" from any process or any terminal (even the console).

As for a daemon's not being able to establish its own process group,
4.1BSD does have a "setpgrp" system call, so a daemon could set its
process group ID equal to its process ID if it really cared to.

As for the idea that "there may not be a /dev/console, but there'll
always be a /" -- a little thought should make it clear that you're in
REAL deep yogurt unless you have /dev/console, because every line in
/etc/rc that redirects output to the console will bomb out (including
the "fsck -p", so auto-reboot fails), and the single-user shell spun
off by "init" is going to be a great help without a console to talk
to!!  Since I've GOTTA have a /dev/console on my system to do anything
at all, then, I lose nothing by having /etc/rc talk to it by default.

-- Rich