BKEHOE%WIDENER.BITNET@cornellc.cit.cornell.edu (06/14/90)
I'm sure this has been brought up thousands of times before, but.. I was using cu over a direct line to another one of our systems here, and started a %take, then aborted it. My process on the other machine hung, as well as on the local one. When I logged back into the local one, my cu process was still alive (but wasn't accumulating any CPU time). I tried everything under the sun (bad, bad pun), then got in touch w/ the sysadmin & she tried to kill it su'ing as well as coming in directly as root, but it just wouldn't die. Oh, the machine's a 3b2/400 under SysVR3.2. Any ideas? Anybody have a program/script/whatever that would take care of those? -- Brendan Kehoe (bkehoe@widener.bitnet) -- Sun Systems Manager
rbottin@atl.calstate.edu (Richard John Botting) (06/14/90)
Brendan Kehoe (bkehoe@widener.bitnet)
writes about a 'cu' process that can't even be killed by 'root'.
Thes have been a common occurence on several UNIXen with different
commands. The problem is that the process is waiting on a higher
priority interupt than the ones that 'kill' can send. Examples:
waiting for a magnetic tape interupt on the OLD BSD versions.
'cu' waiting for the other machine to SHUTUP.
'kermit' waiting (apparently) for a CTRL/Q.
The cure is easy IF you can get to the machine that can send
the interupt and connect (somehow) to the line where the interupt
has to come from.
Often this is impossible and then you just shut the system down for a second
or two.
The following doesn't work
for signal in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
do kill -$signal process-id
done
(I've tried it).
Also - on SCO Xenix/386 - a variation occurs where the unillable process
- we've called them 'Dracula' Processes
tend to get into a deadly embrace with the next getty which 'init'
spawns so that any attempt to clear the line hangs up waiting for
the 'getty' to get out of the way (this is truly strange) BUT
the 'getty' is NOT 'gettying' - the kline is effectively dead.
Hence Dracula - sucking the blood and undead.
I'd love to hear of REAL solution (that means $0 and 1 hour of guru time).
Dr. Richard J Botting
Computer Science Department,
California State University, San Bernardino
5500 State University Parkway,
San Bernardino CA 92407
voice:714-880-5326
rjbottin@Atl.calstate.edu
PAAAAAR@CALSTATE.BITNET
PAAAAAR%CALSTATE.BITNET@CUNYVM.CUNY.EDU
>INTERNET:PAAAAAR%CALSTATE.BITNET@CUNYVM.CUNY.EDU (Compuserve)
PAAAAAR@CALSTATE.BITNET@INTERNET# (Applelink)
dick@silicon.....csusbnet.edu (one of these days)
Quotation: The word "just" in computer documentation means "if you're lucky"mvadh@cbnews.att.com (andrew.d.hay) (06/15/90)
In article <23658@adm.BRL.MIL> rbottin@atl.calstate.edu (Richard John Botting) writes:
"Brendan Kehoe (bkehoe@widener.bitnet)
"writes about a 'cu' process that can't even be killed by 'root'.
[]
"I'd love to hear of REAL solution (that means $0 and 1 hour of guru time).
i've seen this on a 3b2/600 with eports cards; i'm told there's a bug
in the tty driver...
my solution was to 'pump' the eports card (reload its resident
software); then processes associated with those ttys can (in fact,
must) be killed. 3b2 ports cards can't be 'pumped', though. you're
on your own with other machines.
--
Andrew Hay +------------------------------------------------------+
Ragged Individualist | But I thought we were *ALL* iconoclasts! |
AT&T-BL Ward Hill MA | I was just trying to fit in!!! |
a.d.hay@att.com +------------------------------------------------------+Mitchell_B._Erblich.ESAE@xerox.com (06/16/90)
Have you tried killing the parent/grandparent process with a kill -9. A process that is a zombie can not be killed because it doesn't wake up to kill itself and I am assuming (correctly/incorrectly) that the process is becoming a zombie.