28

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.

Andy E
  • 659
  • 3
    No one is stating the obvious... a process owned by "init" should be impossible! This is a very strange situtation! Are you sure? – JoelFan Apr 12 '11 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 Apr 13 '11 at 01: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 Apr 13 '11 at 01:34
  • @JoelFan: yeah, I'm sure. The value for PPID was 1 (init), so it was impossible to SIGKILL the process. – Andy E Apr 14 '11 at 15:08
  • 3
    similar to http://unix.stackexchange.com/a/5648/ – tshepang Jun 05 '12 at 20:57
  • This happens to me somewhat regularly on Ubuntu 11.04, like maybe once or twice a month on average. It is especially a problem when other processes find the zombie process and try using it. Two common examples that come to mind are the Google Talk Plugin and ADB (Android Debug Bridge). Their zombie processes somehow end up as child of init and I am unable to use things like G+ Hangouts or many Android development features until rebooting. I guess I just need to let go of GNOME 2 and upgrade (yes, I tried MATE & many others, nothing beats good old GNOME 2, yet). – Pilot_51 Oct 15 '12 at 03:37
  • I've sent SIGCHLD (and signal #17, which is SIGCHLD numerically) to process 1. $0.02 – Scottie H Jul 16 '19 at 19:38

3 Answers3

36

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).

http://en.wikipedia.org/wiki/Zombie_process

Lesmana
  • 27,439
  • 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 Apr 13 '11 at 01:45
  • 15
    @D.Shawley: init can have bugs though. The init replacement runit has had a bug that causes this issue. – camh Apr 13 '11 at 08:26
  • 2
    init can have defunct children, maybe due to a bug, but it can. Because I am looking at one right now. – studgeek May 03 '17 at 04: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 Sep 19 '17 at 03: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 Nov 10 '20 at 00:30
6

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);
       exit(EXIT_FAILURE);
   }
   exit(EXIT_SUCCESS);
}
wait(NULL);
nazar
  • 61
  • 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 Jun 03 '12 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 Sep 22 '15 at 20:40
0

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

Mike S
  • 2,502
  • 2
  • 18
  • 29