A common reason for unkillable processes is that the processes are 
waiting on a syscall stuck in something that to userland must appear 
atomic. consequently signals delivery is suspended under some 
circumstances, and a process is essentially locked waiting on something 
which likely will never happen. Normally this is harmless, the process will
likely never do anything again. It might be holding locks or some state which
other things are waiting for in turn, but given that the unkillable is 
effectively stopped forever, you can usually safely just remove anything
that that process is holding or controlling. In some cases if it easier to
reboot, but i dont think of any processes offhand which would really be 
so bad to just leave the unkillable one running. 
This is not the same as a zombie, those are processes which are in some 
stages of exiting and have lost their parents along the way. Those are 
eventually picked up by init and allowed to finish exiting. 

If you _Really_ want to wake these processes up, you can find the 
specific address theyre sleeping on, cross your fingers, and write a 
small program to wake them up. No guarantee that they will actually wake up
since they have to check if the wakeup is for them, but it might jolt
them loose again. Finding the channel theyre waiting on, though, might take
some work, likely with a debugger on /dev/kmem. 

Isildur

On Fri, 8 Nov 2002, Jeremy C. Reed wrote:

> Can someone point me to the code or documentation about why some processes
> won't be killed?
> 
> I understand that it is safer to not kill a process when it is in some
> special use. But what if I don't care?
> 
> For example, I have a few processes that just won't die. And it has been
> over a week.
> 
> Two are umounts in synclk. (Which happens to be unmounting /dev/fd0a,
> which can't be used.)
> 
> And one shlight in mntwcnt2.
> 
> And unshlight in vfs_busy.
> 
> (Maybe PR 1247 is related?)
> 
> By the way, this is 1.6 i386.
> 
> I've been looking at kern/kern_sig.c.
> 
> Thanks,
> 
>    Jeremy C. Reed
>    http://bsd.reedmedia.net/
> 
>