Rob Weir <firstname.lastname@example.org> [2002-11-04 00:31:17 +1100]: > On Sun, Nov 03, 2002 at 12:42:59PM +0100, Elimar Riesebieter wrote: > > On Sun, 03 Nov 2002 the mental interface of Kevin Coyner told: > > > kosuke 9026 0.0 0.9 14460 4932 ? D 00:16 0:00 xmms > > > kosuke 9027 0.0 0.0 0 0 ? Z 00:16 0:00 [xmms <defunct>] > I'd say you have XMMS setup to only use one instance at a time. It > should be possible to kill -9 9026 and let XMMS start up again, but 9027 > is here to stay. > > killall -9 xmms > Won't work. <defunct> processes are ones which have died, but the > kernel is keeping them around in case their parent cares about it's > return value. AFAIK, it'll hang around, consuming no CPU time but some > amount of swap, until you reboot. Almost correct. It is true that you can't kill a defuct process. It is already dead. Those are called zombies. It is also true that the system will keep it around without consuming any CPU time because the parent needs the return code. The parent gets the return code by calling the system call 'wait()' therefore we say the parent must wait on the child. But it is not true that it will hang around until you reboot. False. The problem is a bad parent that won't wait on its child. The solution is to kill the bad parent. If you kill the parent then process number 1, the init process, will inherit the child. The init process will wait() on all children that it inherits and once that happens to offload the return code from the child then the system will clean up the process slot used by the child and it will go away. Solution: Kill the bad parent. The zombie (defunct) child will then go away. You can find parents easily using the other syntax of 'ps'. I prefer this command. It will thread parent-child in a hierarchy which you can easily find the bad parents. ps -efH | less Bob 1. System V style syntax, specifically UNIX95, instead of BSD style syntax. The Linux ps is smart enough to know the different and do the right thing in either case.
Description: PGP signature