3b2 Unkillable Processes

[Richard John Botting]

Brendan Kehoe (bkehoe at 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 at Atl.calstate.edu
PAAAAAR at CALSTATE.BITNET
PAAAAAR%CALSTATE.BITNET at CUNYVM.CUNY.EDU
>INTERNET:PAAAAAR%CALSTATE.BITNET at CUNYVM.CUNY.EDU (Compuserve)
PAAAAAR at CALSTATE.BITNET@INTERNET# (Applelink)

dick at silicon.....csusbnet.edu (one of these days)

Quotation: The word "just" in computer documentation means "if you're lucky"