Trouble killing processes in SysV/AT

[vrs]

In article <9233 at sol.ARPA> jpayne at cs.rochester.edu (Jonathan Payne) 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 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)).

This is nearly always because a device wants to write output and the connection
has been lost.  The driver fails to flush pending output (and/or new output)
after the connection goes down.

There is another scenario worth worrying about during driver design:  even
if the driver sleeps at a low priority (as it does in the usual tty line
discipline), a kill will cause the process to try to exit().  The exit()
will mask off all signals and close all files.  When it closes the device
with the lost connection, it sleeps AGAIN, this time with signals ignored.

We've done a fair bit of work on our Multibus drivers since XENIX 3.4 :-).