brianb@marque.UUCP (11/25/87)
In article <911@csun.UUCP> abcscnge@csun.UUCP (Scott Neugroschl) writes: :In article <116@citcom.UUCP> peter@citcom.UUCP (Peter Klosky) writes: :: In specific, our PC AT running SCO XENIX 2.1.3 or 2.2 will :: get itself into a state where there will be a process :: which is a child of init which will not respond to a :: kill request. You can send the kill over and over, and the :: process will still exist. The signal sent is a -9, and the :: process has a WCHAN and is not marked as <defunct> in the :: ps output, so we are pretty sure it is not a zombie. : :I realize this isn't a Xenix question (from me), but we have a similar :problem with our Zilog S8000 running ZEUS 3.2 (Zilog's version of SYS III) :at work (not CSUN). It appears to be related to signal processing. Our :in-house guru tells us that the process is "locked on I/O", implying that :the signal really screwed up the kernel data. We have the same problem with terminals connected to an AT&T UNIX PC. I wrote a program to look at the tty struct and could see that it was indeed "locked on I/O". The state is TTIOW (waiting for output to finish), with characters on the output queue. Judging by pgrp it looks like it's been closed without flushing the buffers. If the code is similar to our source code for the 3b5, then when it is outputting, the priority level is set to not look at signals, then it gets stuck there somehow. So I know what the problem is. Anyone know how to fix it? --------------------------------------------------------------------------- Brian Bebeau Marquette University (space for rent to clever quote) UUCP: {rutgers,nike,harvard}!uwvax!marque!brianb ARPA: brianb%marque.uucp@csd1.milw.wisc.edu DOMAIN: brianb@mu.EDU <--- coming soon to a mailer near you! ---------------------------------------------------------------------------