Path: utzoo!attcan!uunet!ncrlnk!ncrcae!hubcap!gatech!ncar!tank!uxc!uxc.cso.uiuc.edu!uxg.cso.uiuc.edu!uicsrd.csrd.uiuc.edu!kai
From: kai@uicsrd.csrd.uiuc.edu
Newsgroups: comp.unix.wizards
Subject: Re: Ultrix tape job is unkillable!
Message-ID: <43200057@uicsrd.csrd.uiuc.edu>
Date: 16 Dec 88 03:31:00 GMT
References: <476@larry.UUCP>
Lines: 28
Nf-ID: #R:larry.UUCP:476:uicsrd.csrd.uiuc.edu:43200057:000:1304
Nf-From: uicsrd.csrd.uiuc.edu!kai    Dec 15 21:31:00 1988


> Written by jwp@larry.UUCP:
> ...
> so instead of interrupting the process with cntl/C, I pop the
> drive off-line (thinking the jobs will abort).  Later, I find
> the "readtape" job hanging around with a priority of -5, and
> I couldn't kill it.

This problem is not specific to Ultrix.  I've found the exact same thing
occurs on VAX BSD unix, Sequent Dynix, and Alliant Concentrix.  The only
thing that seems to work is a reboot.  I warned everyone here that
interrupting a tape job by putting the drive offline is a tremendous
mistake.

Also, folks using Ckermit (V057C) to dial out occationally get hung up, with
essentially the same thing occuring.  The process cannot be killed (even
during shutdown, you get the message "something wouldn't die - ps axl
advised"), and the device is permanently locked up.  I've found that usually,
a "kill -HUP", "kill -INT", or "kill -QUIT" will actually get rid of a
suspect kermit process, but a "kill -TERM" almost always hangs it (until the
next reboot).

Is this a problem in the device driver, kernel process management, or
something else entirely?  It seems that if an event is being waited for,
there ought to be a way to have the OS force the event to occur or fail.

Patrick Wolfe  (pat@kai.com, kailand!pat)
System Manager, Kuck and Associates, Inc.