[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: harsher kill than kill -9 ?

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?

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...



Reply to: