Dear managers,
I have just received the letter from
Tom Webster <webster_at_ssdpdc.lgb.cal.boeing.com> in reply to my SUMMARY.
I find his letter so useful for many managers that I dare to forward it
entirely. Thanks, Tom.
Irene
---------- Forwarded message ----------
Date: Wed, 3 Jun 1998 23:22:03 -0700
From: Tom Webster <webster_at_ssdpdc.lgb.cal.boeing.com>
To: irene_at_alpha.iae.nsk.su
Subject: Re: SUMMARY: What undesirable may AUTO_ACTION = RESTART bring to?
Irene,
Just a couple of short notes in regards to your summary:
> The consensus is that "shutdown -h" brings the system to console (it's the
> essential addition to what I can see on page 1-3 of Customer Technical
> Information).
In general, you are much better off using "init 0" rather than "shutdown -h".
THis is beacuse under DU, shutdown when run with the either the "-r" or "-h"
flag will issue a killall for all running processes and then reboot or halt
the system. It will NOT run the init-level transion scripts. If you
are running any products that need to be shutdown in an orderly fashion,
like Oracle or other RDBMs, use of "shutdown -[h|r]" will lead to data
corruption.
Issuing an "init 0" will cause the system to immediately start switching
runlevels to runlevel 0 (halt). You may want to warn users with
"shutdown -k" which issues warnings but does nothing else. Another option
is to run shutdown without any flags, this will bring the system down to
single user mode. From there, you can sync the disks using "sync" (this
isn't supposed to be needed anymore but it is part of the ritual) and
run the halt command. (DO NOT run halt while in multi-user mode unless
lives are at stake, it is the only thing worse than "shutdown -[h|r]".)
In talking to Digital Engineering, the shutdown behavior is supposed to be
fixed in DU 5.0 and should run the init scripts when passed the "-r" and
"-h" flages.
> Some possible "annoying results" of setting AUTO_ACTION = RESTART are
> following.
>
> Lucio Chiappetti wrote:
> "I believe the only problem is that if you experience a blackout, and
> have "restart" set, the machine will reboot once power is back. If then
> power is unstable and is lost while booting, you may get corruption on
> the disks (e.g. during the fsck phase).
> So we've set all our machines to "HALT".
> Actually now we've bought UPSs (Uninterruptible Power Supplies, essentially
> a buffer battery), so we could perhaps relax this. Smarter UPSs can be
> programmed to shutdown the machine via a serial connection after so many
> minutes from blackout, and to turn it on when power is back, AND the
> battery is so much percent full (so that a clean shutdown can occur)."
Anything that you refer to as a "server" of any type should really be on
a UPS. In the States they are not that expensive, esp. compared to the cost
of the hardware and the data. With workstations it is more a matter of cost and
how often you have power problems.
> George Guethlein uses "auto_action=restart" on ALL his systems
> (2100, 4100's and 8400) running DEC Unix. But he had 1 BAD situation with it
> when a core dump (after Informix database crashed) filled up the "/" file
> system, and auto reboot failed because "/" was full (system crash), and so on
> (20+ times!). To prevent such things, he just made sure that no applications
> write (dump) to the "/" and has not had the problem ever again.
Been there, done that. Seperating /var onto its own partition and seeing that
it has lots of free space for dumps helps too. If you use nsr, beware of
growing index files in /var/nsr.
> Russel Morison mentions a little "trick" to prevent undesirable reboot:
> "... when you have AUTO_ACTION=restart and you do a shutdown -h now
> the machines shuts down to the console mode. If you power the machine off ,
> and power it back on again the machine will try to auutomatically boot into
> the operating system. If you want to stop it booting into the operating
> system a few control C's at the end of the harware check, just before it
> boots up the kernel normally does the job."
If your Alphas have system keys (different from case or keyboard locks),
like our 8400, the key needs to be in the enable mode for this to work.
If the key is in secure mode, CTRL-C will not halt a boot, and CTRL-P
will not force an immediate halt of a running system. Needless to say,
the system key should be in secure mode unless you are working on the
system, to prevent accidental CTRL-P's. If you are familiar with the old
VAXen, then this should be familiar. On smaller systems, CRTL-C seems to
work at boot time, but CTRL-P is thankfully disabled.
Tom
--
+-----------------------------------+---------------------------------+
| Tom Webster | "Funny, I've never seen it |
| SysAdmin MDA-SSD ISS-IS-HB-S&O | do THAT before...." |
| webster_at_ssdpdc.lgb.cal.boeing.com | - Any user support person |
+-----------------------------------+---------------------------------+
| Unless clearly stated otherwise, all opinions are my own. |
+---------------------------------------------------------------------+
Received on Thu Jun 04 1998 - 08:53:37 NZST