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!oliveb!Glacier!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.unix
Subject: Re: Q's on: System V /etc/init....
Message-ID: <3004@sun.uucp>
Date: Sun, 17-Nov-85 15:55:06 EST
Article-I.D.: sun.3004
Posted: Sun Nov 17 15:55:06 1985
Date-Received: Thu, 21-Nov-85 03:34:45 EST
References: <5749@fortune.UUCP> <2968@sun.uucp> <331@ncr-sd.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 53

> One of the more interesting innovations to recent Unix has been the
> new scheme by which /etc/init brings up terminals.  (I first saw it
> in System V and I don't know if it was in System III, so pardon me
> if I term it a "System V" enhancement.)

It actually was in S3; we used it at CCI to run a variant version of
"getty"/"login" which had a full-screen user interface that was the same as
the one provided by our office automation system.  4.3BSD will (unless they
take it out) have a similar facility.

> > 1. Bring system directly up to multi-user without operator
> >    intervention.
> 
> Yeah, I agree.  All of that operator intervention is unnecessary.  If
> you are blessed with a battery-backup clock on your machine so that the
> date is usually set correctly, \none/ of it is necessary.

What we did at CCI was to have a daemon that supported the DARPA time
protocol (part of the DARPA TCP/UDP/IP/... protocol suite), and have the
machine first try to get the current time from another machine.  If that
failed, it would wait for the operator to type in the correct time and date
(with a reasonable user interface based on (Steve Bellovin's?) "getdate"
routine, not the "date" user interface).  If the operator didn't type in a
date within a certain amount of time (a minute or two), it would go
multi-user anyway and send "root" main warning them that the date may have
been set incorrectly.

> And you \always/ want filesystem checks when the system goes down; only
> in a development environment where you are rebooting frequently can I
> imagine any other choice, and in that environment something special can
> be done.  My particular wrinkle was that if the file /down was present,
> it was assumed that the system was taken down cleanly and the filesystem
> checks were skipped.

4.2BSD's "fastboot" script uses the file "/fastboot" for the same purpose.
4.2BSD has a field in the superblock, "fs_clean", which, according to the
comments in <sys/fs.h>, says "file system is clean".  This flag should be
cleared on a "umount" after all the cached blocks and inodes have been
written to the disk, and should be set as soon as a file system is mounted
read/write.  "fsck -p" could then skip file systems with this flag set.
Unfortunately, the 4.2BSD filesystem code doesn't do this.  I think later
versions of S5 with the "file system hardening" may provide a similar flag.

> This is a good point.  I don't know if an extra entry is necessary, though.
> If bootwait entries didn't write on /etc/utmp it would probably be enough.

Assuming you add your change to have any non-zero exit code from a
"bootwait" line cause "init" to come up in the lowest state specified in
"initdefault", so that you can manually repair the damage (and make sure
that "init" comes up in the highest state specified if you log out from a
single-user shell).

	Guy Harris