jr@oglvee.UUCP (Jim Rosenberg) (06/14/89)
I'm in the process of configuring the first of several AT&T 6386en to be used at our remote locations. In working with our development 6386 it suddenly hit me one day how incredibly dumb and potentially catastrophic is the following lovely "feature" of the UNIX V.3.2 shutdown sequence. Now as you all know, for remote sites where no one is UNIX knowledgeable, shutdown is a most weighty matter, and failing to do shutdown correctly is just about GUARANTEED to cause big-time trouble. I look over at the screen one day after a shutdown has gone to completion, and what do I see as the final line on the screen: Reboot the system now. Think about it. Not "You MAY reboot the system now." Not "You may turn the power off or reboot the system now." Oh no. This is a command. It says: "Reboot the system NOW!" [emphasis added]. Now isn't this fun. You instruct your users in the religion of shutdown. They only know about UNIX what you've told them. You think you have dynamite menu stuff and shell script stuff and the whole works. One day they have to move the machine, so they have to unplug it. Like good little campers they go through shutdown. They are all ready to hit the power switch, and then they see this stern admonition: "Reboot the system now." "Oh, OK, well the computer TOLD ME to reboot ..." So they reboot, chatter with someone else in the office for a minute, then turn the power off ... All right, so AT&T flubbed this, no big deal, I'll just edit whatever shell script has this abortion in it. I look at /etc/rc0. Not there. In desparation I go through every file in /etc. Not there. /etc/rc0.d/*: same story. Finally there is only one place left in all of /dev/universe. I say to myself "I DO NOT BELIEVE THIS!" and run strings on /unix. Yup. This idiocy is HARD CODED INTO THE FLIBBING **KERNEL**!!!! So quick now, all you glorious VARs and systems integrators and other adventurous souls using the 6386, forward march & adb that kernel -- and the .o file for making new kernels and ... -- Jim Rosenberg pitt Oglevee Computer Systems >--!amanue!oglvee!jr 151 Oglevee Lane cgh Connellsville, PA 15425 #include <disclaimer.h>
tneff@bfmny0.UUCP (Tom Neff) (06/15/89)
If you think about it for a second, by the time UNIX is totally ready
to be "rebooted now," you shouldn't have an active file system to
read scripts from. The kernel is ALL THAT'S LEFT. So the message
has to go there. (I suppose it could be linked in at rebuild time.)
It seems sufficient to tell people, "Always run SHUTDOWN before turning
off power. Never power down a running system." If they DO reboot
after a shutdown, they cannot hurt anything without violating your
instructions, since the system would once again be "running."
By the way in my experience with my pair of 6386en, the only danger to
an inadvertent powerdown or crash is to the files you have changed since
the last 'sync' happened. You can reboot the system every 5 minutes all
day long and never lose a thing if you don't change your files (edit etc.)
At worst, some log files might not get updated, but if you're sitting
there rebooting all the time, what's to log anyway.
To minimize the risk from power hits and crashes, I add a root cron job
that performs a 'sync ; sync' every 10 minutes. I have not been reliably
persuaded that this is something the kernel does automatically on V/386,
although I know of UNIXen where that's true. I feel more comfortable
doing it myself -- the overhead is negligible. Only caveat - this doesn't
help files accessed remotely via RFS. I wish there were an RFS equivalent
to force update of the cache but I haven't found one.
Also - to simplify the shutdown procedure in the event of my team's absence
(say, if someone had to run in and shut things off due to an emergency in
the building or an impending power shutdown), I create the following
entry in /etc/passwd:
shutdown:x:0:1:Shut down the system:/usr/shutdown:/bin/sh
and the following /usr/shutdown/.profile:
cd /
exec /etc/shutdown -y -g15
I could do the same thing directly by naming shutdown as the startup
shell, but I hate having to edit /etc/passwd just to change things
like delay options.
--
You may not redistribute this article for profit without written permission.
--
Tom Neff UUCP: ...!uunet!bfmny0!tneff
"Truisms aren't everything." Internet: tneff@bfmny0.UU.NETjfc@athena.mit.edu (John F Carr) (06/16/89)
In article <14401@bfmny0.UUCP> tneff@bfmny0.UUCP (Tom Neff) writes: >To minimize the risk from power hits and crashes, I add a root cron job >that performs a 'sync ; sync' every 10 minutes. I have not been reliably >persuaded that this is something the kernel does automatically on V/386, >although I know of UNIXen where that's true. We have the following man page (and a program to go with it) on our BSD 4.3 system. UPDATE(8) UNIX Programmer's Manual UPDATE(8) NAME update - periodically update the super block SYNOPSIS /etc/update [-n] DESCRIPTION Update is a program that executes the sync(2) primitive every 30 seconds. This insures that the file system is fairly up to date in case of a crash. This command should not be executed directly, but should be executed out of the initialization shell command file. Normally, update opens certain system directories to keep them in the name translation cache. If the -n option is given, subdirectories of /usr are not opened so that remote system libraries can be unmounted while the system is run- ning. It doesn't appear to place much load on a system to do this twice per minute (perhaps 2 minutes CPU per day of runtime). --John Carr (jfc@athena.mit.edu)
les@chinet.chi.il.us (Leslie Mikesell) (06/17/89)
In article <483@oglvee.UUCP> jr@oglvee.UUCP (Jim Rosenberg) writes: >Think about it. Not "You MAY reboot the system now." Not "You may turn the >power off or reboot the system now." Oh no. This is a command. It says: >"Reboot the system NOW!" Well, a common reason to shut down a 386 machine is to bring it up under DOS or a diagnostic disk, so the message isn't always inappropriate. Has anyone else had a problem rebooting with ctl-alt-delete after getting this message? I generally get a rom diagnostic about a serial port failure unless I push the reset button or power down after running unix. Les Mikesell
chris@cetia4.UUCP (Christian Bertin) (06/22/89)
In article <12044@bloom-beacon.MIT.EDU>, jfc@athena.mit.edu (John F Carr) writes: (talking about the 'update' daemon) > > It doesn't appear to place much load on a system to do this twice > per minute (perhaps 2 minutes CPU per day of runtime). > > --John Carr (jfc@athena.mit.edu) If you have a large buffer cache (1Mb on my system) and if you do a lot of compiles, or if you do anything that creates large temporary files, you can waste a LOT of time sync'ing files that should never have been written out to disk. The last time I tried to measure this, a 3 hour compile session went down to 2:40 after I changed the sync time from 30 seconds to 2 minutes. At the very least, 'update' should take an optionnal argument to customize the sync intervals. Chris -- Chris Bertin | -- CETIA -- 150, Av Marcelin Berthelot, Z.I. Toulon-Est +33(94)212005 | 83088 Toulon Cedex, France | inria!cetia!chris
dricejb@drilex.UUCP (Craig Jackson drilex1) (06/22/89)
In article <12044@bloom-beacon.MIT.EDU> jfc@athena.mit.edu (John F Carr) writes: >In article <14401@bfmny0.UUCP> tneff@bfmny0.UUCP (Tom Neff) writes: > >>To minimize the risk from power hits and crashes, I add a root cron job >>that performs a 'sync ; sync' every 10 minutes. I have not been reliably >>persuaded that this is something the kernel does automatically on V/386, >>although I know of UNIXen where that's true. > >We have the following man page (and a program to go with it) on our BSD 4.3 >system. > >UPDATE(8) UNIX Programmer's Manual UPDATE(8) Sometime during the creation of System V, somebody decided that init has plenty of time to toss in a sync now and then. I believe that it does so about once every four minutes or so. (This is plenty of time to reboot the system if you've just fsck'ed root & repaired it.) Personally, I've always thought that update(8) was a hack, ever since I first saw it in Version 7. To think that someone would write an operating system that couldn't even keep its on-disk data structures consistent... Here's a little inews fodder. -- Craig Jackson {bbn,ll-xn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}
vjs@calcite.UUCP (Vernon Schryver) (06/23/89)
The continuing discussion of an old fashioned update(1m) deamon for SVR3 is puzzling. SVR3 has the kernel process which ps lists 'bdflush'. It does better write-behind than a periodic, complete buffer flush flood like the update deamon. In at least some versions, one can tune bdflush's aging parameters. Separately, some file systems are careful to invalidate buffers containing data for unlinked files when the in-core inode reference count goes to 0. Bdflush may never have a chance to write such disk blocks. That strategy can have a measurable effect on the speed of things like C compilers. It is irritating as well as unusual to have to say something nice about System V, but truth is truth. Vernon Schryver vjs@calcite.uucp
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/23/89)
In article <2294@drilex.UUCP> dricejb@drilex.UUCP (Craig Jackson drilex1) writes: >Personally, I've always thought that update(8) was a hack, ever since I >first saw it in Version 7. To think that someone would write an operating >system that couldn't even keep its on-disk data structures consistent... It hasn't been necessary to perform periodic sync()s to maintain the integrity of disk structures for many years now (in the System V branch of the UNIX family tree, at least, and I've heard similar claims for some 4BSD variants). However, sync() does make the disk reflect a more recent consistent state of the filesystem. Without it, a sudden crash could lose lots of kernel-buffered file information.
rk@bigbroth.UUCP (rohan kelley) (06/23/89)
In article <483@oglvee.UUCP>, jr@oglvee.UUCP (Jim Rosenberg) writes: > I look over at the screen one day after a shutdown has gone > to completion, and what do I see as the final line on the screen: > Reboot the system now. > One day they have to move the machine, so they have to unplug > it. Like good little campers they go through shutdown. They are all ready to > hit the power switch, and then they see this stern admonition: "Reboot the > system now." "Oh, OK, well the computer TOLD ME to reboot ..." So they > reboot, chatter with someone else in the office for a minute, then turn the > power off ... > > All right, so AT&T flubbed this, no big deal, I'll just edit whatever shell > script has this abortion in it. I look at /etc/rc0. Not there. In About the only thing you can do is write a shell script in /etc/rc0 like: echo "ANYONE WHO FAILS TO IGNOR THE NEXT MESSAGE WILL BE SHOT AT SUNRISE...." ======================================================================= Rohan Kelley -- UNIleX Systems, Inc. (Systems and software for lawyers) UUCP: ...{gatech!uflorida,ucf-cs}!novavax!bigbroth!rk (office) novavax!mdlbrotr!rk (home) ATTmail: attmail!bigbroth!rk 3365 Galt Ocean Drive, Ft. Lauderdale, FL 33308 Phone: (305) 563-1504 "Go first class or your heirs will" -somebodyelse =======================================================================