Path: utzoo!utgpu!cunews!bnrgate!brtph3!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: infmx!dberg@uunet.uu.net (David I. Berg)
Newsgroups: comp.sys.sun
Subject: <exiting>
Keywords: Miscellaneous
Message-ID: <1545@brchh104.bnr.ca>
Date: 1 Feb 91 21:17:01 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 22
Approved: Sun-Spots@rice.edu
X-Sun-Spots-Digest: Volume 10, Issue 35, message 4
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

From time to time, while I am dialed into our out from a serial port on a
SUN 3/260 (4.0.3) a noise burst will interrupt my session and knock me off
the line. When I am unable to reconnect, I find that the process that was
connected to the modem is <exiting>. This process cannot be killed, and
tip cannot reconnect to the port. The only way I have found to restore a
semblance of normalcy is to reboot. This seems to be a rather harsh
resolution to what should be a simple problem. Any and all suggestions are
welcome, including flames about my procedures, if need be.

[[Ed's Note: The (exiting) state usually indicates that a child process
has exited and is waiting for it's parent to execute a wait() system call
before it goes away (this is the "ZOMBIE" state). Once a process gets in
this state, it can not be terminated by any signal, the only thing that
will clean it out is the parent issuing a wait. From your message, it's
hard to tell, but a couple of haphazard guesses come to mind:
 
   (a) Your actual login process hangs when you get disconnected and 
       thus, CAN'T issue a wait to clean up the children.
   (b) Your child processes are getting orphaned when your main process
       dies and for some reason init isn't adopting them.

I am not really sure how you can remedy this problem. -bdg]]