362

The chrome browser was not responsive and I tried to kill it, but instead of disappearing the process had <defunct> at its right, and didn't get killed:

enter image description here

What is <defunct> for a process and why it doesn't it get killed?

  • 7
    The accepted answer mentions that "kill -9 PID don't work". It's partially true: in reality, NO kill will work. Besides, -9 should be used as a last resort. 99% of the time a default kill of the parent process will kill it AND reap all the children. A "default kill" is a SIGTERM (-15). I encourage fans of the -9 (SIGKILL) to read http://stackoverflow.com/questions/690415/in-what-order-should-i-send-signals-to-gracefully-shutdown-processes/690631#690631 – Mike S Sep 01 '16 at 15:39
  • 1
    https://stackoverflow.com/questions/356722/killing-a-defunct-process-on-unix-system – Aᴍɪʀ Apr 07 '18 at 20:58
  • 2
    names matter a lot, presenting <zombie> instead of <defunct> would explain itself why kill is not an option. You cannot kill a zombie. – Sławomir Lenart Mar 01 '21 at 17:57
  • 1
    I just wanted to add some info that might help others, I use Shutter, a nice image editing tool good for screenshots, and on my Linux machine I have a few CIFS mount points to my NAS box (/mnt/media etc). While running Shutter I turned on NordVPN. Later I found Shutter would not quit and the process became <defunct> and I could not kill it, and trying to restart it didn't work. Even later I turned off NordVPN and Shutter suddenly popped up and worked fine. So, I guess sometimes a <defunct> process is waiting for a network path that has become unavailable. – Neek Feb 13 '25 at 02:30
  • 1
    Specifically, and not sure why no one brought this up, defunct or zombie processes do take up an entry in the process table. In the old days broken kernels didn't reap them and could possibly multiply till the process table was filled and no more processes, which means every command all the suuden fails. Though in this day and age this is not a wory; was a worry back in the 70's and early 80's though. – Ronald Johnson Feb 22 '25 at 10:19

7 Answers7

330

From your output we see a <defunct>, which means the process has either completed its task or has been corrupted or killed, but still has child processes running or its parent process is not monitoring it properly (i.e. it does not run the code to clean it up). To kill this kind of process, kill -9 PID doesn't work. You can try to kill them with that command, but it will remain in the list of processes.

To fix the issue, determine the parent process of the defunct process and kill it. To know the PID of the parent, run the command:

$ ps -ef | grep defunct
    UID    PID   PPID  C   STIME   TTY  TIME      CMD
   1000    637  27872  0   Oct12   ?    00:00:04  [chrome] <defunct>
   1000   1808   1777  0   Oct04   ?    00:00:00  [zeitgeist-datah] <defunct>

Then kill -9 637 27872 (i.e kill of the PID and PPID), then verify that the defunct process is now gone running the ps -ef | grep defunct again.


WARNING (added by Alexis Wilke, not the author): Since I looked into this and this is marked as the accepted answer, I think it's worth having a warning:

  • Before killing the parent, you may want to check what process this is:

     $ ps -ef | grep 27872
     alexis  4927  4360  4 Apr19 ?  13:19:17/usr/bin/gnome-shell
    

    Yep. In my case, the parent is gnome-shell. I probably do not want to kill that one. In this case, I'll have to reboot.

Alexis Wilke
  • 2,787
Paddington
  • 3,602
  • 33
    you can't kill "defunct" process. You only can speed up the deletion of its entry in a process table by killing its parent. – jfs Feb 27 '14 at 20:58
  • 106
    What if the ppid is 1 (init)? Suppose I'll just have to wait? – Luc May 06 '14 at 05:42
  • 13
    to automate the kill, you can do this, too (might need to change which bytes you're cutting from the output): ps -ef | grep defunct | grep -v grep | cut -b8-20 | xargs kill -9 – warren Jan 21 '15 at 19:34
  • 6
    @warren Thanks. You can also make that slightly shorter and (imo) simpler by not doing a second grep. Just change the first grep to grep [d]efunct or similar and it won't match itself. – Vala Jul 26 '16 at 11:35
  • 13
    @warren you can't kill a defunct process- even with a SIGKILL. Furthermore, you're using kill -9 pretty indiscriminately. See http://stackoverflow.com/questions/690415/in-what-order-should-i-send-signals-to-gracefully-shutdown-processes/690631#690631 . If you want to kill defunct children, you might try: parents_of_dead_kids=$(ps -ef | grep [d]efunct | awk '{print $3}' | sort | uniq | egrep -v '^1$'); echo "$parents_of_dead_kids" | xargs kill. Rerun the script after 30 seconds or so, with the kill -9 if you desire. (Note that I specifically disallow killing of Init) – Mike S Sep 01 '16 at 14:50
  • @MikeS I didn't say it was the best option. I said it would speed-up what JFSebastian said. As with any code on the intarwebs, I would expect you to try it before you just deploy it in cron, for example (and gave a disclaimer on which bytes are being cut) – warren Sep 01 '16 at 15:00
  • 1
    @Thor84no the | grep -v grep addition has become habit because it's easier to think about . There are ways of not needing to use it, however - and that is a good suggestion. – warren Sep 01 '16 at 15:01
  • what if this did not work for me? – xeruf May 23 '18 at 21:15
  • 1
    @Xerus Then restart the system. That'll kill all processes. – John Strood Jun 27 '18 at 06:11
  • What @Luc said. Exactly what Luc said. – aroth Aug 22 '18 at 05:35
  • 2
    Why -9 is necessary for parent? – anatoly techtonik Dec 25 '18 at 10:40
  • 1
    If ppid is 1 see https://unix.stackexchange.com/questions/5642/what-if-kill-9-does-not-work/5648#5648 – rogerdpack Apr 30 '19 at 15:26
  • And what if the parent process is uninterruptible? Is there really nothing to do other than restarting the computer? – Andyc May 28 '19 at 17:38
  • I have dozens of defunct processes I can't kill, the shutdown command won't work, and even through the GUI, the shutdown menu won't come up – JoeManiaci Dec 22 '20 at 22:53
  • 1
    this killed my computer – br4nnigan Oct 02 '22 at 17:56
  • if you prefer GUI's then open htop (apt install htop), type t to switch to tree mode, then / to search for your process in the tree, then select its parent process and press k to kill and (optionally) select signal 9 SIGKILL instead of the default SIGTERM – ccpizza Oct 17 '23 at 16:52
93

Manual page ps(1) says:

Processes marked <defunct> are dead processes (so-called "zombies") that remain because their parent has not destroyed them properly. These processes will be destroyed by init(8) if the parent process exits.

You can't kill it because it is already dead. The only thing left is an entry in the process table:

On Unix and Unix-like computer operating systems, a zombie process or defunct process is a process that has completed execution but still has an entry in the process table. This entry is still needed to allow the parent process to read its child's exit status.

There is no harm in letting such processes be unless there are many of them. Zombie is eventually reaped by its parent (by calling wait(2)). If original parent hasn't reaped it before its own exit then init process (pid == 1) does it at some later time. Zombie Process is just:

A process that has terminated and that is deleted when its exit status has been reported to another process which is waiting for that process to terminate.

jfs
  • 4,078
  • 3
    "There is no harm in letting such processes be unless there are many of them". This isn't true. These defunct processes can still keep file handles open (lock files for instance), and ports open. Sometimes there is no saving these processes without a system reboot, as far as I can tell. – Scott Nov 01 '19 at 20:10
  • 3
    @Scott: why do you think a dead process keeps file handles open? Do you have a link to docs, a script that would demonstrate such behavior? – jfs Nov 05 '19 at 18:46
  • Unfortunately I don't have any evidence beyond the fact that I've seen it happen, and I don't know the next time one of the processes will get stuck again to repro. Most recently I verified using "lsof" on a file that it was being held open by the same pid as my defunct process. Previously I've (using netstat/lsof) seen that my defunct process still held the port it was listening on open. This has been enough of a problem that I've built defense in my init.d scripts to wait for the defunct process to clear when doing restarts so the new process can bind the port. Will screenshot if I repro – Scott Nov 06 '19 at 13:08
  • 3
    @Scott: It doesn't look like the issues you've mentioned are related to the process being a zombie as in I would be surprised that a dead process may keep file handles open. Let's avoid unsubstantiated misleading claims – jfs Nov 07 '19 at 10:28
  • 1
    If you don't accept that I've seen defunct processes hold ports and files open, that's fine, but my reasoning is neither unsubstantiated nor misleading. It's substantiated by empirical evidence and the whole reason I said it the first place was to ensure that readers of the answer do not get mislead. Doing some more research, it seems that at least for ports, sockets can stay open, even if the process is technically dead. So the end result for the user is the same, the port is held open. https://superuser.com/questions/1196736/how-can-a-zombie-process-hold-system-resources-like-a-tcp-port – Scott Nov 07 '19 at 18:41
  • 1
    @Scott: is there really a connection between a process being zombie (not just dead) and "port is held open"? (the fact that network resources may outlive a single process is not under question https://idea.popcount.org/2019-09-20-when-tcp-sockets-refuse-to-die/ ) – jfs Nov 10 '19 at 06:38
6

I accidently create <defunct> processes by

  • starting them from the terminal and
  • then putting them into the background by accident (Ctrl+Z) and
  • somehow terminating the programm.

Solution is to try the command fg in every open terminal window. Then the defunct processes disappear.

Phaiax
  • 61
  • 1
  • 1
  • 1
    bg works just as well - anything that unfreezes the process from the shell which still holds the handle to it. – Rick Moritz Oct 12 '21 at 15:48
3

Adding to @Paddington's answer, I added this function to my bashrc for quick checking:

defunct(){
    echo "Children:"
    ps -ef | head -n1
    ps -ef | grep defunct
    echo "------------------------------"
    echo "Parents:"
    ppids="$(ps -ef | grep defunct | awk '{ print $3 }')"
    echo "$ppids" | while read ppid; do
        ps -A | grep "$ppid"
    done
}

It outputs something like:

Children:
UID        PID  PPID  C STIME TTY          TIME CMD
user     25707 25697  0 Feb26 pts/0    00:00:00 [sh] 
user     30381 29915  0 11:46 pts/7    00:00:00 grep defunct
------------------------------
Parents:
25697 pts/0    00:00:00 npm
2

I made a script in python to automatically find and kill all defunct processes, here it is in case it is useful for someone:

import os
import re 

Find defunct processes and save them to temporary file

os.system("ps -ef | grep defunct > zombies.txt")

pids = []

Load data from defunct processes file and remove the file

zombies = open("zombies.txt", "r").read() os.system("rm zombies.txt")

print(zombies)

For each zombie process, find the integers correspoding to the PID and PPID

for z in zombies.split(" "): ints = re.findall(r'^[-+]?([1-9]\d*|0)$',z) if len(ints)==1: pids.append(ints[0])

There should be 3 integers per process

assert len(pids)%3==0

Kill process by PID and PPID

for i in range(len(pids)//3):

os.system(&quot;kill -9 &quot;+pids[3*i]+&quot; &quot;+pids[3*i+1])

PabloVD
  • 21
1

Thank you Mike S. We took your line and wrote a script that will kill defunct processes whose parent is in.telnetd. We didn't want it to kill any parent process, just telnetd that we know is causing a problem and we'll run it multiple times to kill multiple ones if needed.

# egrep -v '^1$ = Make sure the process is not the init process.
# awk '{print $3}' = Print the parent process.

first_parent_of_first_dead_kid=$(ps -ef | grep [d]efunct | awk '{print $3}' | head -n1 | egrep -v '^1$')
echo "$first_parent_of_first_dead_kid"

# If the first parent of the first dead kid is in.telnetd, then kill it.
if ps -ef | grep $first_parent_of_first_dead_kid | grep in.telnetd;then
        echo "We have a defunct process whose parent process is in.telnetd" | logger -t KILL-DEFUNCT-TELNET
        echo "killing $first_parent_of_first_dead_kid" | logger -t KILL-DEFUNCT-TELNET
        kill $first_parent_of_first_dead_kid 2>&1 | logger -t KILL-DEFUNCT-TELNET
fi
0

I had a libreoffice application zombie hanging with and 'Z'. and its PPID was 1 (because I had killed the calling application oosplash after LibreOffice wasn't responding anymore). However, no files were in use by the zombie. Still, the office icons were still on my desktop/taskbar.

I have managed to get the application (or process ID) cleaned up and being able to start libreoffice again without the need for a reboot:

First, I removed the .lock file in the ~/.config/libreoffice/ directory. (don't know if it is relevant, but just for completeness of what I did). Next I started libreoffice on another host (so under same login). Office started normally on this new host. At the same time: all the 'hanging' libreoffice icons were gone. Once 'Document recovery' was complete, I had closed all open documents and exited libreoffice on this new host. (Please note that the document files are on a fileserver that is accessible to both hosts.)

I restarted libreoffice on the original host and that went without problems and no need to reboot.

Maybe the recipe doesn't work all the time, maybe a coincidence with my host cleaning up the orphan process at precisely the same time, but I was lucky to avoid the reboot. Maybe it helps others as well. just give it a try.

Good luck!

Niels
  • 1