dustin@spy.net wrote:
> 	I made a mistake in an expect script earlier (didn't close/wait)
> and the process that I spawned will not go away.  It's sitting there
> marked 'IEs+' and has been for quite a while.  The process that parented
> this one ran off and left it a while ago, so it can't finish properly.
> Any suggestions other than closing and waiting?  I'm running 1.1.

I'm suffering from a similar problem.  Sometimes, a Kermit process (or
some other process which uses a serial port heavily) is left in an
unkillable state, often as a result of an attempt to terminate it with
a signal.

  UID   PID  PPID CPU PRI NI   VSZ  RSS WCHAN  STAT TT       TIME COMMAND
     0  4748  4563   0   4  0   552  120 ttyout IE   04-   0:00.73 /p/bin/kermit

Here's my theory about what happens:

When a process exits (e.g., having received a fatal signal), all its
open file descriptors are automatically closed by the kernel.  If one
of these file descriptors is a "com" device which is currently
transmitting and still has buffered data, the close will not finish
until all the buffered data has been transmitted.

Now if the draining of the output buffer is stopped by some flow
control mechanism (XOFF or CTS) before the buffer has drained
completely, the exiting process will be left in an unkillable state.
Further signals will have no effect, because the kernel masks all
signals (including SIGKILL) before it begins closing the file
descriptors (see exit1() in kern_exit.c).

I have tried to resurrect com ports left in this state by fiddling
with CTS, sending XONs from a terminal, and by invoking "stty" and/or
"ttyflags" with various parameters, without success.

I don't have any solution to this problem, other than making sure 
that the process closes the "com" device explicitly before exiting.
-- 
Andreas Gustafsson, gson@araneus.fi