Best way to kill Zombie and D state processes in linux

Question

What is the best way to kill Zombie processes and D state process by single command.

Related: https://unix.stackexchange.com/questions/5642/what-if-kill-9-does-not-work/70372#70372 — lepe, Dec 04 '18 at 03:37

score 25 · Accepted Answer · answered Mar 22 '11 at 12:30

Double tap.

Actually, reboot. There's no real way to easily get rid of a zombie, but there's really no reason to because a zombie isn't taking up resources on the computer; it's an orphaned entry in a process table. Init is supposed to collect it but something went wrong with the process. http://en.wikipedia.org/wiki/Zombie_process

Perhaps you're asking because there's worse problem...are you getting a boatload of zombies roaming your process table? That usually means a bug in the program or a problem with a configuration. You shouldn't have a huge number of zombies on the system. One or two I don't worry. If you have fifty of them from Apache or some other daemon, you probably have a problem. But that's not directly related to your question...

there are around 10 zombie process – vnix27 Mar 23 '11 at 10:21 — vnix27, Mar 23 '11 at 10:21
What are the processes? – Bart Silverstrim Mar 23 '11 at 12:45 — Bart Silverstrim, Mar 23 '11 at 12:45

score 19 · Answer 2 · edited Oct 06 '12 at 09:55

19

/sbin/reboot

You can't kill a zombie - its already dead

If the ppid still exists, then terminating that can often clean up the spawned zombies.

You shouldn't be killing processes in uninterruptible sleep - usually this means they're i/o bound, but IIRC it can also occur during a blocking read from e.g. a network socket.

edited Oct 06 '12 at 09:55

quanta

50,327
19
152
213

answered Mar 22 '11 at 12:30

symcbean

19,931
1
29
49

score 14 · Answer 3 · answered Apr 06 '14 at 07:05

14

Errors in underlying filesystem or disks might cause I/O bound processes. In this case try to "umount -f" the filesystem they depend upon - this will abort whatever outstanding I/O requests there are open.

answered Apr 06 '14 at 07:05

Arie Skliarouk

598
1
5
12

2

And lose data. Doesn't sound like a great idea. – Michael Hampton Apr 06 '14 at 13:59
8

You lose data anyway by reboot. This way you might avoid reboot - useful feature on production or development systems. – Arie Skliarouk Apr 07 '14 at 15:07
2

Thanks, this worked for an issue we had with a script stuck attempting to access a disappeared NFS mount for weeks :) – BT643 Nov 19 '14 at 16:33
1

This is exactly what is happening to me sometimes when I do the `ls` command on a s3fs mount. The `ls` process won't kill even with `kill -9` until I force the unmount with `umount -l`. Alternatives to umount? – Marco Marsala Oct 02 '15 at 15:11
@ArieSkliarouk Freaking awesome. Thanks for this little tidbit. – Dustin Oprea Dec 16 '16 at 04:44
2

Now my umount process is hung as a zombie STAT "D+"! – Curtis Yallop Aug 01 '17 at 18:32

score 1 · Answer 4 · edited Dec 11 '21 at 19:23

1

Next line will kill all zombies

ps -xal | grep defunct | awk '{ system (" kill -9 " $4 ) }'

edited Dec 11 '21 at 19:23

Swisstone

6,357
7
21
32

answered Dec 09 '21 at 11:06

Valery Ryazanoff

11
1

This might also kill the ssh shell you're connected with. – Tim Chaubet Mar 09 '22 at 22:15

score 0 · Answer 5 · answered Jan 06 '22 at 03:24

Most answers focus on Zombies, this targets D state

Processes that are stuck in "uninterruptible sleep" show up in a process list as being in state D

In my experience, these are frequently blocked on I/O in some way. If you've been reading files from a mounted network disk and the remote host has restarted or network connectivity has failed in some way, then the copy process can be stuck waiting indefinitely.

The only fixes are to just kill the process, or to umount -f /mnt/source to unmount the disk, and then the process will see that it has gone, and will fail cleanly. Obviously the I/O action will be incomplete too, likely with a partial file copy.

Related, tar and rsync process can be in this state while running through SSH - they are literally blocked waiting for the network to catch up. Point is that state D is not necessarily bad, so killing them all may not be an ideal solution.

Best way to kill Zombie and D state processes in linux

5 Answers5

Linked