Re: can't kill a PID
On Sun, 2002-11-03 at 12:31, Bob Proulx wrote:
> Rob Weir <rweir@softhome.net> [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
Reply to: