kill -KILL fails to kill process

[Oliver Fromme]

Steve Franks wrote:
 > Which I thought was impossible.  Neophyte question, no doubt, but
 > googling was less than helpful (which probably means I'm fubar, no
 > doubt).  Anyway, I have a certain common X app (xmms) that likes to
 > hang (since my last buildworld, it seems) when when it's right about
 > to open a file-choosing dialog.  The only way to get rid of it is to
 > reboot.  Now, given the behavior, I'd have to suspect something
 > underlying as the true source of the problem, but shouldn't kill kill
 > it anyway - I mean, isn't there some way to kill a process that's
 > stuck waiting on a child process?  I haven't figured out how to "ps
 > -ax grep | some neublous file dialog process" yet...so I'm sort of
 > stuck wanting to kill the parent...

If you can't kill a process (even with SIGKILL), it means
that the process currently can't be put on the run queue,
because only processes that are able to run can receive
signals.  Given that, such a situation usually has one of
these three reasons:

1.  The process hangs in "disk wait" (flag "D" in ps' STAT
    column).  This often means there's a hardware problem
    with your disk or controller (or a driver bug), or a
    network problem if you use NFS.

2.  The process was suspended (SIGSTOP).  In this case
    there is the flag "T" in ps' STAT column.  Try sending
    a SIGCONT to the process.

3.  The process terminated, but the parent process failed
    to pick up the exit code.  In this case, the process
    needs to retain an entry in the process table (shown
    by ps) in order to record the exit code until it is
    picked up, even though the process itself is gone.
    Such a "dead" entry in the process table is called a
    zombie process.  In ps' STAT column there is the "Z"
    flag.  This usually indicates a programming error
    (a.k.a. bug) in the parent process.  You can get rid
    of the zombie by killing the parent process.  Then the
    zombie will be inherited by the next process in the
    hierarchy (up to the init process 1 if required) which
    will then pick up the exit code and release the process
    entry.

There can be other reasons on occasion, but those three are
the most common ones.  Simply look at the STAT column in
the ps(1) output for the process in question.  It will tell
you the reason why the process is stuck.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

Passwords are like underwear.  You don't share them,
you don't hang them on your monitor or under your keyboard,
you don't email them, or put them on a web site,
and you must change them very often.