Can't kill wget process with `kill -9`

Question

I have a wget process that I am unable to kill. This question is similar as one asked before, but here the D in the STAT column seems to indicate that it is in uninterruptible sleep (usually IO), while in the other question the process was in state R.

$ ps -axuf | grep `id -un`
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
[...]
biogeek   2833351  0.0  0.0      0     0 ?        D    Apr12   0:03 [wget]
[...]

Trying to kill it doesn't produce any output

$ kill -9 2833351

and when I run ps -axuf again, the wget process is still there.

How do I figure out which software/hardware fault caused this issue?

Answer 1

Since the process has received a SIGKILL, it will die when it returns from its current system call. Furthermore the kernel will make the process return as soon as it gets into a state where it can safely abort the system call. A process only remains in uninterruptible sleep (state D) for a long time if something unusual is happening inside the kernel. For more information about unkillable processes, see What if 'kill -9' does not work?

One way to investigate what the process is doing is to run a diagnostic tool such as strace or dtrace or other similar tools, depending on your unix flavor. This will tell you what system call the process is making and with what arguments. For example, you might see something like this:

strace -p2833351
strace: Process 2833351 attached
read(3, 

This tells you that the process is currently reading from file descriptor 3. The next step would be to find out what's on this file descriptor, for example with lsof -p2833351 or with ls -l /proc/2833351/fd/3. This could point to the origin of the problem, for example a non-responding NFS server or a buggy disk controller that left the filesystem driver in an unexpected state.

You may also find clues in the system logs. The clues may be difficult to find because this is unusual behavior that can be caused by very different things that would have very different telltale signs. It could be a kernel bug directly related to what the process is doing, an unrelated kernel bug that corrupted some memory, defective RAM that corrupted some memory, a defective peripheral such as a disk drive that isn't responding when it should, etc.

Answer 2

Given a status of D, your only options are to wait for the disk I/O operation which is blocking wget to complete (successfully or otherwise), reboot, or ignore the stuck process. You can potentially look at the process tree to find that wget' proccess's parents or children (if any), or at that process's /proc/PID/fd data to look at any open file handles and poke any processes that might also be holding those file handles open.

Answer 3

try just: sudo kill {pid_process}