Oliver Elphick wrote: > > On Sun, 2002-11-03 at 12:23, Rupert wrote: > > > > 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. > > > > > > > > > > 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 > > > > > > > > > > Just tried that, and the monster continues to live ..... > > > > > > Kevin > > > > I've done something along the lines of > > > > while killall -9 xmms; echo -n .; sleep 1; done > > > > in the past, with varying success. > > If kill won't work, killall and the like won't; they are merely > convenient front-ends to kill a collection of process all at once. > > Sometimes a process gets stuck waiting for an event that is never going > to happen. xmms (9026), in that ps report, is in state D - > uninterruptible sleep. It's probably waiting for some kind of IO > event. Because it is uninterruptible, it never wakes up to find that it > has been killed, so it won't go away, even for a SIGKILL (kill -9). > Process 9027 is dead, but it won't go away until its parent (9026) wakes > up and cleans up; until then it is in state Z - zombie. > > I think you will have to reboot the machine.
Try kill -3 or -6 or -11. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
