[wplug] killing process that will not die

Michael Skowvron skowvron at verizon.net
Thu Aug 7 12:24:12 EDT 2003


Kuzman Ganchev wrote:
> I don't think that three is a priority assigned to sigals based on the
> user, but I might be wrong.

Correct. The only requirement is that the signalled process belong to 
the current user unless the user is root.

> If the process is in the middle of a
> system call though, I think it runs in kernel space. 

Yes. A system call, by definition, implies running in kernel mode.

> This means that
> there are no signals it can't ignore... I know this is the case for
> kernel threads (a signal is just a flag that gets set, and the thread
> has to be nice about listening). 

Sort of. Any process/thread can mask or ignore certain signals if 
programmed to do so. There are other signals that cannot be masked or 
ignored (KILL, STOP, CONT). Running in kernel mode or not has no bearing 
on whether it is ignoring or responding to signals. You are also mostly 
correct about it being a flag. I think that the signal check is 
performed at the time the thread is scheduled. However, if the thread 
gets stuck in the system call because it is waiting for a sync variable 
or semaphore to clear, then it will never get scheduled again and never 
see the signal.

This is what I believe happened to the unkillable process. It reached a 
barrier and was not allowed to continue executing until a certain 
"thing" happened. Most likely this would be some kind of sync variable 
or semaphore. I speculate that it is probably related to coordination of 
the various threads within the process. It's definitely a bug, but there 
is no way to determine it's origin. It could be a kernel bug relating to 
the scheduler, a bug in the threads library, or a bug in the processes 
code itself.

To determine the source of bug would probably require the use of a 
kernel debugger. The system would have to be interrupted and dropped 
into the kernel debugger so that the state of the thread could be examined.

see http://oss.sgi.com/projects/kdb/ and
http://lkcd.sourceforge.net/

Michael




More information about the wplug mailing list