On Sun, 2002-11-03 at 12:31, Bob Proulx wrote: > Rob Weir <[EMAIL PROTECTED]> [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 [1]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.
How about killing these? ps -efH |less [SNIP NORMAL OS STUFF] root 31132 1 0 Oct31 ? 00:00:00 [usb-storage-0] root 31133 1 0 Oct31 ? 00:00:00 [scsi_eh_2] [SNIP NORMAL OS STUFF] Yes, the device was unmounted and removed properly. Each time I start the device back up it adds another entry and moves it's SCSI mount point (/dev/sdd1 ---- /dev/sde1 --- /dev/sdf1). So far I've only found a reboot to clear the entries. Ideas? G -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
