which has the parent process of a make command (I killed the parent process, but nothing happened)
ictest00301 35661 0.0 0.0 6280 320 19- I Tue04PM 0:00.01 make execute
The specific process is blocked (cannot be killed) with the following wait channels:
[root@zafora ~]# procstat -t 35662
PID TID COMM TDNAME CPU PRI STATE WCHAN
35662 100196 c1 - 2 122 sleep umtxpi
35662 100997 c1 - 0 122 sleep umtxpi
35662 101757 c1 - 1 122 sleep uwait
35662 102464 c1 - 2 120 run umtxpi
Even though I have implemented resource limits in /etc/login.conf as to the CPU usage, they cannot be enforced, and the server's logfile is filled with messages:
Mar 23 13:06:46 zafora kernel: pid 35662 (c1), uid 1100301, was killed: exceeded maximum CPU limit
but nothing happens. Of course
kill -9 35662
has not effect.
How I can kill this process? If one student managed to make an un-killable process that gets 100% of the CPU with restrictions cannot be enforced, then soon the server will be filled with such processes, and a
reboot will be mandatory.
Re: Un-kill-able process hang at umtxpi state with 100% cpu
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 :)
> Following an advice from a user of this list,
> I did a
> kill -STOP 35662
> in order to minimize the CPU consumption
> and as soon as I hit enter the process disappeared (died). I had already
> killed its parent, but
> it was not possible to kill this process. By sending the STOP signal it was
Are you sure? STOP usually does exactly what it says on the tin. It's
like Ctrl-Z in the shell. You can in theory use 'kill -CONT pid' to
wake the process up again.
If the process died from a SIGSTOP it must be because there were other
pending signals that could somehow be delivered once the process was
stopped, but that strikes me as pretty odd.
> 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
> 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.