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: > > > > > I always thought that with 'kill -9 PID' you could clean up just about > > any process, but I've run into one that just won't go ... > > > > sakura:~$ ps aux |grep xmms > > 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've tried 'kill -9 9026 9027', but every time I go back and ps/grep it, > > it's still there. And in the meantime, if I try to start a new xmms, it > > will start a new PID in addition to 9026, but the program itself won't > > show up. 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. It's icky, but you could edit your ~/.xmms and change the allow_multiple_instances=FALSE line to allow_multiple_instances=TRUE to let you start a new instance. Maybe deleting the xmms_username.0 socket from /tmp would help as well. > > Brainwashed from too many early years in the MS world, I'm tempted to > > reboot. But hoping there's a better, Linux way to clean this up. > > killall -9 xmms > > HTH 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. -rob
Attachment:
pgpsClZPNKgBX.pgp
Description: PGP signature