Hello,
On Tue, 17 Jun 2008, Pawel Wiecek wrote:
> On Jun 17, 2:43pm, Kapil Hari Paranjape wrote:
> > Once you have killed the process it is not really using anything
> > except possibly keeping some swap space tied up.
>
> _If_ it got killed. But it did not. Take a look at that snippet from top, it
> was RUNNING and eating 100% CPU. This was AFTER sending several SIGKILLs to
> it. The only thing that helped was rebooting the machine.
I agree that an unkillable process is unacceptable.
However, _that_ is clearly some sort of serious kernel bug.
KILL 9 exit this signal may not be blocked
So "kill -9 {process id}" should always kill a process.
Note that one should always try "kill -15 {process id}" first.
Secondly, "index++" does not block the TERM(15) signal. All that
could happen with the TERM signal is that under POSIX systems, the
TERM signal requires the process to wait for child processes to
terminate before terminating. Now, if a child process of "index++"
does not exit with "kill -15 {process id}" then "index++" will not
exit either. In that case the better option is to first issue
"pkill -9 -P {process id}" which will kill the children of the
"index++" process and then issue "kill -15 {process id}". (Of course,
if the problem is with grandchildren and so on the problem is more
complex).
Regards,
Kapil.
--
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
