Hi all
Thanks to:
From: Brian O'Neill <Brian_ONeill_at_uml.edu>
From: Paul Crittenden <crittend_at_storm.simpson.edu>
From: Jim Harm <harm1_at_llnl.gov>
From: "Degerness, Mandell ITSD:EX" <Mandell.Degerness_at_gems2.gov.bc.ca>
From: Douglas Wang <douglaswang_at_usa.net>
i think brian and paul may have the right idea of what the problem is, and
jim and douglas have encountered the same problems/temporary solutions.
my summary, original question and responses are below.
I am not sure i have an answer for sure, but I have some idea of what was
holding it up. My advisor who works on the computer, was a VMS person
until 1/2 a year ago. he even had me put edt on his alpha when he
switched over - he wouldn't switch until we had it! so he is still very
unused to DU commands, and his alias' consist of pages of DU commands
aliased to VMS names. we are making progress tho it may be slow. Well,
I recently discovered that he will often freeze up a window while using
edt and he was unable to figure out how to get rid of it. so he would
send it to his fourth virtual terminal and leave it there. he logs out
infrequently and so a frozen window (and hanging process) grave yard would
build up. I am sure he also had some other "stuff" hanging around. When
i learned of this i taught him about the kill command. He also still
maintains one window to log into the dying VMS VAX he is weaning himself
from. I was not actually present when this was done, but the next time
the computer was shut down the same thing happened - it just sat there.
My advisor and another student began killing processes and closing windows
that weren't hung (he keeps upwards of 2 netscapes, one graphics display
window called saoimage, 12 terminals, a ghostview or ghostscript or three,
and probably an xv as a background display - we refer to this as a
windhorstian number of windows). apparently after the right processes were
killed, the computer shut down as instructed. My guess is that we are
having problems because of hung terminals and maybe a process or two that
was also hanging. Next time the computer is shutdown i hope to 1)log out
the advisor first 2) see what is hanging and kill it. 3) then shutdown
and watch what happens.
FYI it is an alpha 200 4/166. I'm not keen on a patch solution cause i
know some of them interfere with proper working of some astronomical
software we need, and i am a grad student without the time needed to try
to fix the patch/software problem.
i will only comment on the issue concerning the dangers of shutdown -h and
the need to use init. i have been informed by beings i know to be more
intelligent than i when it comes to alpha computers that shutdown -h is a
script that calls init. i did read the man pages and indeed i find:
"At shutdown time a message is written in the system log,
containing the time of shutdown, who ran shutdown and the reason.
A terminate signal is then sent to init to bring the system down
to the single-user state. Alternatively, if you invoke shutdown
with the -r, -h, or -k flag, the command executes the reboot
command or the halt command, or avoids shutting the system down.
Note that the -h and -r flags use a broadcast kill signal and not
the run level transition scripts. To use the run level transition
scripts, execute the shutdown command without the -h or -r flag. This
will bring the system down to single user mode. From single user
mode, execute shutdown with the -h or -r flag. Alternatively, you
can execute init 0 which will bring the system from level 3 to the
console prompt.
i only point this out because i looked into the different possible
problems and eliminated this one because of this.
Thanks!
Claudia
*********************************************************
* Message From: *
* Claudia-Angelica Teresa Chiarenza Burg *
* aka Gigi *
* Claudia *
* G^2 *
* Currently Computing From: Arizona State University *
* Working on: a PhD in Physics and Astronomy *
* Claudia.Burg_at_asu.edu *
*********************************************************
>
>Hi
>
>I searched the web (learned a few things as always) but i am not sure of
>the problem - it seems most like a bug in earlier (<3) versions, but as i
>am at du4.0b (no patches) that seems exceedingly unlikely (impossible).
>
>the problem: Twice now i have attempted to do a shutdown on the same alpha
>and had it fail (no prob on four others). i can either sudo, su or login
>as root and then type shutdown -h now and the computer says system going
>down immediately, but then it doesn't. i can even logout - if it is
>myself as opposed to root - and login again as root and issue the command
>without luck. the first time it happened was a few months back when i
>was changing the time on the clock shortly after the new installation of
>du4.0b. this time, it occurred when i went to cycle the power after a user
>had issued a control^c while dumping to a dat (screwing it up). it turned
>out we may also be having troubles with the scsi cable length and have
>removed a periferal to check this out. The scsi length was definitely
>not a problem the first time it happened as there were fewer devices then.
>
>is it an odd effect of the scsi being unhappy?
>is it processes hung or too many getty processes as in the archives?
>
>it is not a big problem - i don't think, as the command often works. any
>thoughts or what to look for are welcome.
>
>Thanks!
>
>Claudia
From: Brian O'Neill <Brian_ONeill_at_uml.edu>
I used to see this problem when we had a prevalence of LAT terminals
connected to DECserver 100s. These terminal servers didn't use hardware
flow control - and therefore if a user turned off a terminal, the server
couldn't tell. This would leave LAT ttys under Digital UNIX hung, and
the system couldn't shut down properly, at least not with shutdown,
because shutdown itself would hang trying to notify the user on that
tty.
From: Paul Crittenden <crittend_at_storm.simpson.edu>
There is a patch for that in the jumbo patch kit for the Alpha 2100 if
that is the type you have. I had the same problem and the patch kit
fixed it. Another thing to look at is the be sure that not one is logged
in using LAT. This will cause your system to hang on shutdown also.
I believe there is a patch for that also.
From: Jim Harm <harm1_at_llnl.gov>
We have had the same problem more than once with 4.0b and
turned it in to DEC with a control-P crash dump.
I haven't seen it lately with 4.0d.
We were able to watch the shutdown continue after we started killing processes.
We got to a particular user that was running some background processes
that were monitoring system performance.
But the process was a script sleeping!
We had a work-around and so many other problems that it has taken a back seat
for too long. We will revive our request to DEC support.
One of the arguements from DEC is (occasionally)
no one else is having this problem, so it will be a low priority for us to fix.
If you have reported it to DEC, give me the trouble call sequence number.
Mine is C970919-4606.
Try killing off leaf(bottom child) processes until you find the one that
is holding up the shutdown command and send it to DEC.
From: "Degerness, Mandell ITSD:EX" <Mandell.Degerness_at_gems2.gov.bc.ca>
I would not recommend using shutdown -h. It is very dangerous and on at
least some versions of DU it does not shut things down nicely (via the
rc scripts).
Instead, use the command "init 0" to do what "shutdown -h now" would
normally do. If it seems to take to long, check the console messages,
there should be some status messages printed out by the rc shutdown
scripts indicating how far it is getting.
If you really don't care about running the rc scripts, hit the halt
button :-) (note: I don't recommend this).
Regards,
Mandell Degerness
From: Douglas Wang <douglaswang_at_usa.net>
Dear Claudia,
Any solution has had for your "doesn't shutdown"----because I had the
completely same problem at serveral days ago just like you. Hope receive
your SUMMANY.
TIA
Douglas
Received on Tue May 05 1998 - 23:06:37 NZST