Processes that won't die

[E Frank Ball]

On Mon, Nov 12, 2001 at 02:02:26PM -0800, Eric Eisenhart wrote:
} ps -ef doesn't show the "STAT" field, though; next time run 'ps ax | grep
} rmb'.  I have no idea what rmb is, but the most frequent reason I've seen
} for kill -9 not working is that a process is in the "D" state
} (uninterruptible sleep) which usually means that the process is blocking on
} I/O.

Devin said:
} A process that won't die under a sigkill is either blocked in some protracted
} and unlikely fashion or you're looking at a kernel bug.  Unless you had I/O
} issues just then, I suggest investigating the latter possiblity.

I'm using Kernel 2.2.12, but I'll consider updating (up2date errored out
on me).  rmb is known for blocking kill signals in "protracted and
unlikely fashions", but netscape usually responds to kill -9.  rmb likes
to generate many processes for each window and if it doesn't get stopped
in just the right way it makes it's self a real pain in the ass.

So if something is in a "D" state I'm hosed?
(I'll look next time I get things good and stuck).

"rmb" is "Rocky Mountain Basic" 
http://www.tamsinc.com/basic/blx.htm

You'll puke when you see the price, but our price for internal Agilent
use is much much cheaper (their linux product was based our our source
code from HPUX).  We have millions of lines of code for rmb for our
manufacturing test areas, so if we can use rmb on linux instead of rmb
on hpux we can save $4000 per test station on computer hardware, which
makes $100 or so for software look pretty cheap.  Some of this code
dates back to the early 80's when we used "rmb workstations" running on
HP 9000/200 series hardware.  It's actually not a horrid choice of
environments for our instrument test (heavy I/O via GPIB and some RS232
and VXI).  Its easy to debug tests and the I/O and measurement time of
the instruments limits how fast it can run more than anything else.

-- 

   E Frank Ball                efball at efball.com