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?

Possible dupe of How to kill a task that cannot be killed (uninterruptable?) or How to kill a process which can't be killed without rebooting? — Kusalananda, Apr 26 '21 at 15:49
Does this answer your question? How to kill a task that cannot be killed (uninterruptable?) — DopeGhoti, Apr 26 '21 at 15:54
@Kusalananda Neither of these threads, nor the reference question on the topic which is https://unix.stackexchange.com/questions/5642/what-if-kill-9-does-not-work, discuss how to investigate what a D-state process is doing and how it might have gotten into this jam. — Gilles 'SO- stop being evil', Apr 26 '21 at 16:07

score 16 · Accepted Answer · answered Apr 26 '21 at 16:06

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.

score 1 · Answer 2 · answered Apr 26 '21 at 15:56

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.

score -3 · Answer 3 · edited Oct 21 '21 at 12:31

-3

try just: sudo kill {pid_process}

edited Oct 21 '21 at 12:31

Chris Davies

116,213
16
160
287

answered Oct 20 '21 at 20:07

user497820

1

3

It doesn't seem as if the problem is permissions in running the kill command, it is that the process is not responding to the KILL signal - so sudo might not make much difference. Also, your suggestion will just send the (default) TERM signal. – Greenonline Oct 21 '21 at 01:30

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

3 Answers3

Linked