Hi,
On my Linux machine, using Bash, I sometimes run into a situation where doing the following does not seem to work at all.
kermit@fastbox ~ $ ps -A | grep firefox-bin
5375 ? 00:06:57 firefox-bin <defunct>
5624 ? 00:00:00 firefox-bin
kermit@fastbox ~ $ kill 5624
kermit@fastbox ~ $ ps -A | grep firefox-bin
5375 ? 00:06:57 firefox-bin <defunct>
5624 ? 00:00:00 firefox-bin
kermit@fastbox ~ $
Why is kill not killing the process?
What most often "defunct" means is a 'zombie' , so you have to 'kill'em all' 
you can either "pkill -9 firefox" - guaranteed that all processes with firefox in their names will die, though it's dangerous, or, you can 'kill -9' which is not the most elegant way, but it works. The regular kill is the default, nice way, whereas -9 flag cannot be ignored.
Ok thanks. I ended up rebooting, but the next time I have an issue such as that with Firefox, I will give your suggestion a try.
kill with no signal number "asks politly to the process to end"
so, if its zombied, it wont reply
be a macho and use -9 
You can't kill a zombie, that's what zombie means, it's already killed but it won't go away.
only process can be killed.
zombie is not at all a process.
It just represents its existence in the past occupying a slot in the kernel process table and as such it is not a process
Hi Sysgate,
I don't understand when you use the term - "most often"
Does that mean a non-defunct process can be zombie ? 
I haven't heard of this before or came across such.
Would you mind giving some explanation about this ? 
Um, yeah. I've seen it in commercial, proprietary application. Developers have chosen to put <defunct> tag in the process' name not when the process becomes zombie, as this is the only parent, but when it was trying to acquire certain number of open files, which may be impossible at this time, due to ulimit limitation for example. On the same application, <defunct> has been chosen as generic error message, just as in perl's warn : "Warning: Something's wrong" when $@ is empty.