Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!think!snorkelwacker!bloom-beacon!eru!luth!sunic!mcsun!unido!mikros!mwtech!martin
From: martin@mwtech.UUCP (Martin Weitzel)
Newsgroups: comp.unix.xenix
Subject: Re: Failed kill -9
Message-ID: <551@mwtech.UUCP>
Date: 17 Dec 89 00:40:20 GMT
References: <[628]unix@oldcolo.UUCP> <25893F64.22E7@marob.masa.com>
Reply-To: martin@mwtech.UUCP (Martin Weitzel)
Organization: MIKROS Systemware, Darmstadt/W-Germany
Lines: 32

In article <25893F64.22E7@marob.masa.com> daveh@marob.masa.com (Dave Hammond) writes:
>In article <[628]unix@oldcolo.UUCP> dave@oldcolo.UUCP (Dave Hughes) writes:
>>How else, short of a reboot, can I kill a process on a port that
>>kill -9 won't kill?
>
>If the process is sleeping waiting for i/o (the `ps -l' PRI value will
>be 20 or less), you can not kill it.  The only answer is to reboot.

True answer in the first part. One thing should be added:
Many drivers sleep non interuptable, if they are waiting for
flow control to become active (ie, if output is stopped by
hardware- or XOFF-protocoll).

A typical example is a printer, that has run out of paper. If
you switch the printer off now (because the page printed
accidentially was the last one you wanted to be printed), the
printing process might still hang, waiting for XON. If you kill
the process, it will not go away. Assuming your printer sends
XON right after power on, the hung (and allready killed)
process vanishes right after you switch your printer on again.

BTW: If the device was not opened in exclusive mode, then you
can flush the queue with an appropriate 'ioctl'-call from another
process (executing a small program, not to difficult to write in C).
In most cases this will also wake up (and if allready killed, also
terminate) the hung process, because after flushing the queue
there is no reason for the driver to wait for flow control to
become active.


-- 
<<< MW -- email: see header -- voice: 49-(0)6151-6 56 83 >>>