Re: harsher kill than kill -9 ?

[David Fuchs <dfuchs@uniserve.com>]

The `D' tells you that the process is in an uninterruptible disk wait 
state.  This can only be caused by a kernel problem with the i/o 
routines, a filesystem problem, or a device driver problem.  There 
really isn't anything you can do but restart the machine to get rid of 
that process unless you're lucky enough to have it return from it's wait 
(not likely).

   For some explanation, a problem like this is caused when an 
application tries to read/write from disk, but the i/o call never 
returns, and it doesn't result in a timeout either.  `kill -9', as most 
of you know, is used to send SIGKILL to a process.  The SIGKILL signal 
can not be blocked, ignored, or handled by an application in any way, 
which means that once your application receives a SIGKILL, it's done 
for.  The reason it doesn't work in this situation, however, is that the 
program needs to accept the signal that's trying to be sent first.  It 
can't do this while it's waiting to return from it's disk activity.

   If you'd like something to read, check out "Advanced Programming in 
the UNIX Environment" (Stevens 1992).  It's got some very useful 
information regarding signals and how they're handled.

-David Fuchs

Daniel Patrick Berdine wrote:

> On Thu, 12 Jul 2001, Andrei Ivanov wrote:
>
> > Well, if its a zombie process, it'll go away by itself after a while.
> > Can you send an output of ps aux for that process (or top), please?
> > Andrei
>
> not zombie...
>
> 19355 rothaar    9   0 90588  88M   476 D     0.0 17.6   0:01 plot.out
>
> from top.
>
> I actually had dpkg do the same thing the other day when I tried to
> install a third part .deb. Eventually got it to work fine, but it got hung
> up at dpkg --config.  I thought it was just a fuke of what I was doing at
> the time or something, but maybe not...
>
> I run dozens of apps very similar to this every day for my work, the only
> thing special about this one was that I was trying to run it with a
> certain array as large as possible.  It kept segfaulting because I didn't
> have neough memory I guess, until this one, which just sortof sits there,
> munching up memory but no CPU (luckily! :) )
>
> The array was 1,000,000 x 2 x 2 x 1 and it was trying to make 100 copies,
> so I don't blame the machine for complaining a bit, but I'd really like to
> kill the stupid thing...
>
> Thanks,
>
> -Dan