[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