[wplug] killing process that will not die

[Michael Skowvron]

Kuzman Ganchev wrote:
> Processes can't exactly ignore signals...
> Kernel threads are not interruptable...

Ah, yes. Much better details on signals than I provided.

>>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.
> 
> Process or thread? kernel threads don't make system calls -- they are
> already part of the kernel. I think that while in a system call,
> processes behave like kernel threads -- i.e. it's up to whoever wrote
> the system call to make sure they eventually return if they get a
> signal, but I'm not 100% sure about that. 

Process thread, of course. I am in the habit of calling everything a 
thread because I work with Irix. In Irix, everything that executes is a 
thread (user threads, service threads, interrupt threads). A user thread 
is absolutely identical to a kernel thread or an interrupt handler 
thread. The concept of the "process" is actually an accounting structure 
that references the underlying thread or threads that are associated 
with that "process."

And sure, you are right that the expectation is for the system call to 
return in a timely manner so that signals can be checked. If the system 
call doesn't return [in a timely manner], then there is probably a problem.

>>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.
> 
> 
> A user level thread library shouldn't affect recieving SIGKILL, since
> the whole set of threads should be a single process. Unless I'm
> missing something about thread libraries that use kernel
> functionality. 

I understand it as the kernel provides the locking mechanisms that the 
threads use for synchronzation and the threads library implements the 
logic of setting and releasing of those locks. An unkillable process (or 
thread) becomes unkillable becuase it's not properly returning from some 
system call. In many cases, this can be traced back to some thread 
holding a lock that some other thread needs. Often times, the bug is 
that two threads end up grabbing locks that the other one needs. A 
deadlock condition is then created and everything else that might be 
tied to those threads appears to freeze.

Michael