Transmission is intermittently hanging on my NAS. If I send SIGTERM, it doesn't disappear from the process list and a <defunct> label appears next to it. If I send a SIGKILL, it still doesn't disappear and I can't terminate the parent because the parent is init. The only way I can get rid of the process and restart Transmission is to reboot.

I realize the best thing I can do is try and fix Transmission (and I've tried), but I'm a novice at compiling and I wanted to make sure my torrents finished before I start messing around with it.

  • 3
    No one is stating the obvious... a <defunct> process owned by "init" should be impossible! This is a very strange situtation! Are you sure?
    – JoelFan
    Commented Apr 12, 2011 at 19:17
  • @JoelFan: I was just looking that up to make sure that I wasn't forgetting something important. Zombies that are children of init should go away pretty quickly since init waits on children periodically as one of its many common tasks... is <defunct> the same as a zombie?
    – D.Shawley
    Commented Apr 13, 2011 at 1:31
  • 1
    nevermind ... <defunct> is precisely the same as a zombie. init will wait on its children so this should never happen in theory. I wonder what happens if you send a SIGCHLD to init?
    – D.Shawley
    Commented Apr 13, 2011 at 1:34
  • @JoelFan: yeah, I'm sure. The value for PPID was 1 (init), so it was impossible to SIGKILL the process.
    – Andy E
    Commented Apr 14, 2011 at 15:08
  • 3
    similar to unix.stackexchange.com/a/5648
    – tshepang
    Commented Jun 5, 2012 at 20:57

3 Answers 3


You cannot kill a <defunct> process (also known as zombie process) as it is already dead. The system keeps zombie processes for the parent to collect the exit status. If the parent does not collect the exit status then the zombie processes will stay around forever. The only way to get rid of those zombie processes are by killing the parent. If the parent is init then you can only reboot.

Zombie processes take up almost no resouces so there is no performance cost in letting them linger. Although having zombie processes around usually means there is a bug in some of your programs. Init should usually collect all children. If init has zombie children then there is a bug in init (or somehwere else but a bug it is).


  • 9
    init can never have zombie children. From the wikipedia article: When a process loses its parent, init becomes its new parent. Init periodically executes the wait system call to reap any zombies with init as parent. One of init's responsibilities is reaping orphans and parentless zombies.
    – D.Shawley
    Commented Apr 13, 2011 at 1:45
  • 15
    @D.Shawley: init can have bugs though. The init replacement runit has had a bug that causes this issue.
    – camh
    Commented Apr 13, 2011 at 8:26
  • 2
    init can have defunct children, maybe due to a bug, but it can. Because I am looking at one right now.
    – studgeek
    Commented May 3, 2017 at 4:03
  • There is this program which I ran from terminal and entered into defunct state.. As explained by @lesmana, when I closed the terminal(parent) the program exited cleanly.
    – Sandeep
    Commented Sep 19, 2017 at 3:05
  • Update, November 2020 on Debian 10 for AMD64: Right now, I had to power off my machine because of an init child zombie process blocking me from using my computer. VMware Player hung. VMX spawns as a child of init. I killed it, but it went into zombie state as a child of init. No matter how many times I sent SIGCHLD to both VMX and init, the process never went away. It blocked me from using my desktop environment, so I had to shut it down. I logged in over SSH from my phone and issued reboot, but after 12 minutes the processes never stopped. I ended up hitting the power button.
    – RAKK
    Commented Nov 10, 2020 at 0:30

Anyone trying to fix the Transmission C source code should read about the "double fork" trick to avoid zombies and signal handlers ... and how it can be used as part of a smart variadic spawn function (see Spawning in Unix).

excerpt from: 
   "Spawning in Unix", http://lubutu.com/code/spawning-in-unix

Double fork
This trick lets you spawn processes whilst avoiding zombies, without 
installing any signal handler. The first process forks and waits for its 
child; the second process forks and immediately exits and is reaped;
the third process is adopted by init, and executes the desired program. 
All zombies accounted for, since init is always waiting.

if(fork() == 0) {
   if(fork() == 0) {
       execvp(file, argv);
  • 1
    The double fork prevents zombie processes by forcing the kernel to set its parent to PID 1, which is supposed to clean up zombies. It sounds like Transmission already does it, since its parent is already process 1.
    – Jander
    Commented Jun 3, 2012 at 21:48
  • 1
    There are multiple problems here. #1: Only the parent should call exit(3); the children should call _exit(2) instead (otherwise you get multiple stdio flushes, among other issues). #2: That execvp(3) could use a perror(3) if it fails. #3: You should just use signal(SIGCHLD, SIG_IGN) instead of this whole mess.
    – Kevin
    Commented Sep 22, 2015 at 20:40

Today I found a process that is defunct, owned by init, and significantly utilizing system resources. Obviously there's a bug somewhere, but I wanted to let future visitors know that it's possible, and they should take a look at threads of the Zombie for more information. See https://stackoverflow.com/questions/22234609/defunct-processes-using-cpu/67840842#67840842

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .