mats@fortune.UUCP (Mats Wichmann) (11/06/85)
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!matsguy@sun.uucp (Guy Harris) (11/09/85)
> 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.
greg@ncr-sd.UUCP (Greg Noel) (11/17/85)
>>> This is a reply to two long articles. Even though I've tried <<< >>> to cut it back to the minimum, it's still quite long (about <<< >>> 175 lines). If you are adverse to long articles, stop now. <<< 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 is interesting because could have been so very useful had it been fully implemented. What has happened is that /etc/init has become a superdaemon, capable of keeping track of other processes (not just login processes), starting and stopping them based upon a control file and a settable run level. Mats Wichmann (below) identifies some flaws and Guy Harris tries to offer some help (but may have missed the point), but I think the real flaw was that the \only/ product in System V that can be run under /etc/init is getty. There are at least three other standard products that could have been trivially modified to run under the superdaemon (cron, lpsched, and errdemon); this would have made them more visible, more controllable, and more useful, and it would have provided a model for other daemons to follow. And it would have made the system easier to control and manage. Instead these daemons are hidden in /etc/rc, they exert magic (that can't be circumvented) to put themselves in the background, and stopping and restarting them is essentially a black art. I have requested that AT&T fix this, but the last I heard, they weren't planning to. Sigh. I'll get off my soapbox and try to be useful now. I'm sorry to have foamed at the mouth so, but it really bugs me that an idea as good as this has been essentially crippled by incomplete implementation. In article <5749@fortune.UUCP> mats@fortune.UUCP (Mats Wichmann) writes: > ..... 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. 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. If your system reboots on power failures and there is no operator in attendance, it is \very/ irritating to have to drive all the way in to work to tell it that I don't want to set the silly date. I ended up taking that out; I'd rather have the system up with the incorrect time than be awakened at 3am and have to go hit a carriage return. 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. (The standard shutdown procedure set this file; it encouraged its use -- and people quickly learned that taking the extra minute to shut the system down cleanly saved ten minutes when rebooting.) And if a file /.AskCheck was present, the operator would be asked for a decision. (This was for the times when you were testing something that crashed the system; it was assumed you knew what you were doing and would remove the file before normal use.) Otherwise, the filesystems were always checked; it was simply a part of the reboot process. > 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...). Absolutely. First, I will describe a technique that \usually/ works; then I will froth at the mouth a little more about how it \should/ have been done. Some background: I use init level 2 for normal multiprogramming and init level 1 for "single user" mode (it's actually multiprogramming but the only terminals enabled are those within shouting distance of the computer itself). (I also use init level 0 to shut the system down; it runs a locally-modified /etc/shutdown script.) Normally, the system tries to come up at level 2, but if one of the /etc/*rc scripts detects a failure, it executes "/etc/init 1; exec sleep 90" which, assuming it isn't a full moon, bring the system up at level 1. (When the moon is full, it will wedge the system. Also, when the moon is new, this has no effect. But it's better than nothing.) The system can then be repaired as necessary. Unfortunately, it is usually necessary to reboot the system again as it is not generally possible to restart the initialization sequence. What should happen? Simple. It's not commonly known that initdefault can contain more than one value; init just selects the highest run level as the one to execute. If an initwait entry fails (returns non-zero), init should just select the \lowest/ initdefault level instead. This would go a long way toward making this whole thing easier to use. Are you listening AT&T? > 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. I think both of these are really the same complaint, and that is that it is difficult for /etc/rc to determine which daemons need to be started or stopped for the new run level. But this is \exactly/ what /etc/init does already. If it were only possible to run the daemons by specifying them in /etc/inittab, /etc/init could start and stop them for you. In fact, I am fortunate to have sources so this is just what I have done. The only change to the source is to find the line that says approximately "if (fork()) exit(0);" and comment it out. You can't really avoid running /etc/rc when changing levels, but now the job that it has to do is managable. > 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 have reported this bug to AT&T, but I'm told that it is still being released. It's actually very strange, because the manual entries very carefully explain what \not/ to put in a inittab entry. The actual command in the file has an "exec" prepended to it and the whole thing is passed to the shell. This means that exactly one command can be executed. Now, you can just see someone thinking, "I need to execute more than one command on this line, so how can I do it? Why, of course, I get the shell to run a subshell! I just put the entire command string in parenthesis!" So /etc/init constructs "exec (rm .....)" and hands it to a shell. The shell throws up its hands in disgust, and the virtual system console never gets relinked to the hardware console. The solution is to put the code sequence into one of the /etc/*rc files -- it's not particularly critical which. This one is \so/ flagrant that I didn't believe it when I saw it -- I wondered if some joker put it in deliberatly just so he could snicker every time he looked at a S5 port and found it there, since he would know that the vendor's checkout process was so poor. (Take a look in your /etc/inittab file -- does it have the line?) In article <2968@sun.uucp> guy@sun.uucp (Guy Harris) replys: > .... ((( some commentary about fsck, not related to the actual problem > of getting the /etc/rc script to interrupt and switch to single user))).... >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 >... (((a punishment that I don't consider severe enough))). .... >We fixed this at CCI. I added a "bootcheck" "inittab" item; this item is >NOT recorded in /etc/utmp. .... (((More details about the overall flow >of the scheme.))) .... 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. My trick to provide a single-user mode is that the first entry in inittab is a bootwait entry for getty with a timeout on it. If you don't log in on the console within 60 seconds, it times out and the rest of the boot sequence is run. If that fails, it tries to go into init level 1. I am reasonably happy with this; the safety net seems sufficient. > .... (((Some more stuff about fsck, not relevant here. A plug for > Chris Torek's "preen" program, which I will second. I'll never figure > out why "fsck -p" wasn't like this all along...))) ..... >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)? ..... Because of the way I manage the system, I haven't had the problems with the virtual console comming up in a funny mode, but I \have/ wondered what the logic behind /dev/{console,syscon,systty} is. And have you ever tried to boot a system with no /dev/syscon? Even if /dev/console is there, if it can't find /dev/syscon, it just tries to print out an error message (which gets lost because /dev/syscon isn't there) and dies. It's \hard/ to get it out of that state..... Pardon the spelling; it's 3am and I just don't feel like editing this. -- -- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA
guy@sun.uucp (Guy Harris) (11/17/85)
> 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
clyde@ut-ngp.UUCP (Head UNIX Hacquer) (11/19/85)
Hmm. Almost hate to say this, but the 'init levels & automatic reboot' discussion falls into my category of "Yet another reason to pitch System V into the trash". :-) (Of course, who knows what violence has been done to init/getty in 4.3) -- Shouter-To-Dead-Parrots @ Univ. of Texas Computation Center; Austin, Texas "All life is a blur of Republicans and meat." -Zippy the Pinhead clyde@ngp.UTEXAS.EDU, clyde@sally.UTEXAS.EDU ...!ihnp4!ut-ngp!clyde, ...!allegra!ut-ngp!clyde
karsh@geowhiz.UUCP (Bruce Karsh) (11/20/85)
In article <331@ncr-sd.UUCP> greg@ncr-sd.UUCP (Greg Noel) writes: > >What has happened is that /etc/init has become a superdaemon, capable >of keeping track of other processes (not just login processes), starting >and stopping them based upon a control file and a settable run level. >Mats Wichmann (below) identifies some flaws and Guy Harris tries to >offer some help (but may have missed the point), but I think the real >flaw was that the \only/ product in System V that can be run under >/etc/init is getty. There are at least three other standard products >that could have been trivially modified to run under the superdaemon >(cron, lpsched, and errdemon); this would have made them more visible, >more controllable, and more useful, and it would have provided a model >for other daemons to follow. And it would have made the system easier >to control and manage. > This has been done on Masscomp systems. Here are some lines from our /etc/inittab file: 1:xx::/etc/getty console ! 0 1:up:c:/etc/update 2:cr:c:/etc/cron 2:up:c:/etc/update 2:nd::/etc/net/netd 2>/usr/adm/netd.log 2:wd::/etc/net/rwhod 2>/usr/adm/rwhod.log 2:00:c:/usr/local/holdline /dev/tty0 2:18:c:/usr1/karsh/D/LOCAL/getty-b tty18 Y -- Bruce Karsh U. Wisc. Dept. Geology and Geophysics 1215 W Dayton, Madison, WI 53706 (608) 262-1697 {ihnp4,seismo}!uwvax!geowhiz!karsh
chris@umcp-cs.UUCP (Chris Torek) (11/20/85)
In article <2621@ut-ngp.UUCP> clyde@ut-ngp.UUCP (Head UNIX Hacquer) writes: > Hmm. Almost hate to say this, but the 'init levels & automatic reboot' > discussion falls into my category of "Yet another reason to pitch System V > into the trash". :-) > > (Of course, who knows what violence has been done to init/getty in 4.3) Very little, actually. Instead, they have been cleaned up quite a bit. I have heard that the new /etc/ttys format was done at MIT; it is, by the way, also in Ultrix 1.1, judging from the manuals---which were incorrectly typeset: all the tabs except the first were squashed out. Extracted from our own /etc/ttys: # # name getty type status comments # console "/etc/getty 4" dw on secure # console tty00 none sd off # to CVL tty01 none sd off # to CVL tty02 "/etc/getty sd" sd on # Gandalf [...etc...] ttyhe "/etc/getty N7" N7 on # Nau 4337 ttyhf "/etc/getty Dq" Dq on # 4364 DT80#18 ttyi0 "/etc/getty aaa" aaa on # 4364 ttyi1 "/etc/getty N7" N7 on # Reiter 2313 ttyi2 "/etc/getty N7" N7 on # Lan Do 4309 [...etc.] with careful `gettytab' setup, most every entry can simply read tty<n> "/etc/getty <type>" <type> on This, and having everything in one file, greatly reduces organizational headaches. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
cspencer@bbncc5.UUCP (Clifford Spencer) (11/20/85)
> a bit. I have heard that the new /etc/ttys format was done at MIT; > it is, by the way, also in Ultrix 1.1, judging from the manuals---which [insert nit pick here] Ahem, make that Ultrix 1.2 -cliff -- cliff spencer {harvard, ihnp4, decvax}!bbnccv!cspencer cspencer@bbncc5
allbery@ncoast.UUCP (Brandon S. Allbery) (11/24/85)
> > 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. Speaking of which... I am on S3 and have a need to write a replacement for getty... without source. What does a child of init have to do to make the system happy? I was able to dope it out in V7 (actually Xenix), but I can make neither hide nor tail of S3 -- my attempts uniformly were failures. (My most successful one worked fine iff you didn't want to use a program which opened /dev/tty -- maybe I was missing a setpgrp()?) Responses to ..decvax!cwruecmp!ncoast!tdi2!brandon -- that's where they will be used. I will post a summary of responses. DON'T POST YOUR RESPONSE. Thanks in advance, --Brandon -- "This civilization, too, must be allowed to fall..." Brandon S. Allbery ncoast!allbery@Case.CSNet (ncoast!allbery%Case.CSNet@CSNet-Relay.ARPA) ..decvax!cwruecmp!ncoast!bsa -- maybe ..genrad!mit-eddie!futura!ncoast!allbery 6615 Center St., Mentor, OH 44060 (I moved) --Phone: +01 216 974 9210 CIS 74106,1032 -- MCI MAIL BALLBERY (WARNING: I am only a part-time denizen...) ncoast is dead, long live ncoast!
ccc@cwruecmp.UUCP (Case Computer Club) (11/25/85)
In article <3004@sun.uucp> guy@sun.uucp (Guy Harris) writes: >> 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. > The current release of System V Release 2 for 3B2's provides this flag (called s_state). There's also a program called 'fsstat' which examines this flag and returns an appropriate status so the rc files can decide whether or not to run fsck on the device. Carl Fongheiser ...!decvax!cwruecmp!ccc (or) ...!decvax!cwruecmp!happy!cmf (or) cmf%happy@Case.CSNET (or) cmf%happy%Case.CSNET@CSnet-relay.ARPA
mats@fortune.UUCP (Mats Wichmann) (12/10/85)
Hmmm, I missed a lot of this conversation, I guess. Guy didn't miss
the point in answering my questions (at least the questions I asked).
And using init to watch over other daemons is really quite simple -
you just need to not have the daemons "deamonize" themselves
(i.e., DON'T fork and have the parent exit). It's like three lines
or so - if you are being elegant (otherwise just delete the fork/exit
lines). That way, init can find out when they die and restart them.
Nice, eh? We made those changes at Dual when I was there.
I have since unmade them. Why? It's really kind of nice to be able to
stop a daemon without having to do things like: "edit inittab so cron
does not get respawned in init stat 6, then switch to init state 6."
If you ever have to reset your system clock you should stop cron.
If lpsched is dying, something is wrong, so you probably don'y
want to restart. It is also a bitch to change your configuration,
since most changes require the scheduler to be off. And so on.
Turns out most "idiocy" is not as idiotic as it appears at first.
Dual still runs the network daemons from inittab, and this makes
some kind of sense, since they provide a service that is more
directly needed by users, and it would be inconvenient to have
to find the system admin. to restart them if they were dying
(although he should probably be trying to find out WHY).
Mats Wichmann
Fortune Systems
{ihnp4,hplabs,dual}!fortune!mats
"Quality. Comfort. Style.
And at prices jou can afford!"
- Izzy Moreno