Trouble killing processes in SysV/AT

Jonathan Payne jpayne at cs.rochester.edu
Mon May 2 09:21:11 AEST 1988


In article <3967 at killer.UUCP> richardh at killer.UUCP (Richard Hargrove) writes:
>In article <3951 at killer.UUCP>, wnp at killer.UUCP (Wolf Paul) writes:
>> Can anyone enlighten me as to what causes a process to become "immortal"
>> in System VR2,  or Microport UNIX System V/AT, to be more specific?
>> 
>> I have encountered this a number of times, where it would be impossible
>> even for root to kill a process; 

>Not having access to source code, I was left to speculate on what I observed.
>I came to the conclusion that the actual processes were gone, but some
>table or tables maintained by the kernel had been corrupted. I'm assuming
>that ps reports only what it finds in the table(s) and that it doesn't check
>their validity. As you experienced, rebooting the system cleared up
>everything. If my diagnosis is correct, I know of no other way to clear up
>the problem, though I would like to more about what was going on.
>
>richard hargrove
>...!{ihnp4 | codas | cbosgd}!killer!richardh
>--------------------------------------------


I believe the story goes something like this.  The process is sleeping at
a priority that is too high (or low) to be interrupted by a software
interrupt.  That is, while in kernel mode the process did a sleep(chan1,
PRI), but nothing has come along to wake it up (with wakeup(chan1)).
Sending a signal can't wake up a process that is sleeping in this
manner.  I believe something like this happened to me several years ago
when my pty was expecting a ^Q (because somehow it got a ^S ...) and I
got disconnected but it was sleeping in the tty driver waiting for that
^Q.  Software interrupts, I believe, are checked whenever a process is
schedule for running.  Sending the signal sets some bit in the process
structure, and when the process is next schedule those bits will be
checked.  The problem is that the process is still sleeping, waiting for
some event, like a ^Q or some other kind of interrupt, and unfortunately
that interrupt may never come for some reason (like I was disconnected
from the pty - this bug is fixed, I think).

(I pretty sure about this ...)



More information about the Comp.unix.microport mailing list