Un-kill-able process hang at umtxpi state with 100% cpu

jd1008 jd1008 at gmail.com
Mon Mar 23 19:11:19 UTC 2015

On 03/23/2015 12:32 PM, BBlister wrote:
> The process named c1 in the home directory of that student, had an
> accompanied c1.c file that actually is one that spawn many working pthreads
> and synchronizes them at the end. I executed by a normal user
> and nothing strange happened.
> So I assume that was a rare timing issue/race condition that triggered this
> error.
> I will have to upgrade of course to 9.3 in order to rule out old problems.
> So, the takeaway of this is that sometimes when kill -KILL does not work,
> kill -STOP may do the job :)

About signal 9 (SIGKILL)

    The SIGKILL signal is sent to a process to cause it to terminate
    immediately (*kill*). In contrast to SIGTERM and SIGINT, this signal
    cannot be caught or ignored, and the receiving process cannot
    perform any clean-up upon receiving this signal.

So, the only way a process cannot be killed by a signal 9 is if it is 
sleeping on an uniterruptible
priority (such as when it is holding a lock on a system resource, and 
sleeps waiting for an even
from low lever driver or other process (thread) (which will send a wake 
signal to the sleeping process). And as soon it is awakened, it is killed
and the resource is released.

This is why that I suspect that signal STOP did not kill your process
that was not killable by SIGKILL (9).
What happened is that possibly, the process had woken and the system
finally delivered the SIGKILL to to it. I believe you had a conicidence of
sending the STOP and then you saw that the process had disappeared.
As you know a lot of time can pass  (as far as the cpu is concerned)
between doing a ps command, seeing the process still running, and then
issuing a kill command and then doing ps again to see that
the process has disappeared.



More information about the freebsd-questions mailing list