Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!hao!hplabs!pesnta!greipa!decwrl!sun!guy From: guy@sun.uucp (Guy Harris) Newsgroups: net.unix Subject: Re: Q's on: System V /etc/init.... Message-ID: <2968@sun.uucp> Date: Sat, 9-Nov-85 02:56:35 EST Article-I.D.: sun.2968 Posted: Sat Nov 9 02:56:35 1985 Date-Received: Tue, 12-Nov-85 05:08:21 EST References: <5749@fortune.UUCP> Distribution: net Organization: Sun Microsystems, Inc. Lines: 76 > 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.