Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!umich!samsung!zaphod.mps.ohio-state.edu!mips!apple!motcsd!hpda!hpcuhb!hpihoah!shaw
From: shaw@hpihoah.HP.COM (Joy-lim Shaw)
Newsgroups: comp.unix.questions
Subject: Re: kill -9 PID fails.  why?
Message-ID: <4480004@hpihoah.HP.COM>
Date: 2 Feb 90 02:57:02 GMT
References: <657@buster.irby.com>
Organization: Hewlett Packard, Cupertino
Lines: 36

/ hpihoah:comp.unix.questions / rli@buster.irby.com (Buster Irby) /  8:08 pm  Jan 27, 1990 /
>ric@ace.sri.com (Richard Steinberger) writes:

>>Sometimes I see a user has been logged on several days without doing
>>anything.  ps shows that the process is sleeping, waiting for input.
>>Many times I am unable to kill such a process.  What I have been doing
>>is kill -9 PID, where PID is the user's process ID.  Could someone
>>shed some light on why such processes don't die.  Is there a particular
>>document that I might peruse to understand this situation better?  And
>>if kill -9 doesn't work, do I have any alternatives other than reboot?

How these software  signals work, is that  periodically  a function that
checks  the  signal  queue is run on your  behalf.  This is done,  among
other time, when a process  switches mode (User mode to Kernal mode, and
visa  versa).  So when a process is waiting for a driver, and the driver
is waiting for a hardware signal, it never checks the signal queue until
it  returns  from  the  driver.  In  short,  that  process  is just  not
listening to your signals.

To kill this  process, one usually has to reboot the machine, but if you
know that this  process  is waiting  for a signal for say a tape  drive.
Try putting the tape drive back on line or some other  things to get the
tape  drive to  generate a hardware  signal.  Any signal  will do as the
driver is probably  listening for anything.  But usually  you'll have to
reboot to kill that process.  Of course if the process isn't causing any
problems other then being there, why reboot?  Let it sit there until you
can reboot at a more opertune (sp) time or its next scheduled down time.

For more  information  you can try looking it up in a UNIX kernal  book.
The Bach  book must  have it.  And for more  information  as to when the
signal  queue is checked,  you'll have to check with the folks who wrote
your kernal.

Hope this helps.

shaw