dave@oldcolo.UUCP (Dave Hughes) (12/13/89)
How else, short of a reboot, can I kill a process on a port that kill -9 won't kill? For some reason a port with a 9600 baud Robotics dual standard on it sometimes locks up after a user disconnects. And either a getty is on the port or a 'login' process. But neither a kill -9 on the process number will kill it or even result in a changed process number. And it is unaffected if I disable the tty with 'disable ttya5'. SCO Xenix 2.2. I also can't force anything out it, or use a 'cu' on it. Its as if it has seized the process. Dave Hughes Old Colorado City Communications "It is better to light one screen than cursor the darkness" hplabs!hp-lsd!oldcolo!dave
daveh@marob.masa.com (Dave Hammond) (12/16/89)
In article <[628]unix@oldcolo.UUCP> dave@oldcolo.UUCP (Dave Hughes) writes: >How else, short of a reboot, can I kill a process on a port that >kill -9 won't kill? If the process is sleeping waiting for i/o (the `ps -l' PRI value will be 20 or less), you can not kill it. The only answer is to reboot. -- Dave Hammond daveh@marob.masa.com uunet!masa.com!marob!daveh
ag@amix.commodore.com (Keith Gabryelski) (12/16/89)
In article <25893F64.22E7@marob.masa.com> daveh@marob.masa.com (Dave Hammond) writes: >If the process is sleeping waiting for i/o (the `ps -l' PRI value will >be 20 or less), you can not kill it. The only answer is to reboot. You should also note that this is most probably a bug in the driver and should be fixed and/or reported. Pax, Keith -- ag@amix.commodore.com Keith Gabryelski ...!cbmvax!amix!ag
martin@mwtech.UUCP (Martin Weitzel) (12/17/89)
In article <25893F64.22E7@marob.masa.com> daveh@marob.masa.com (Dave Hammond) writes: >In article <[628]unix@oldcolo.UUCP> dave@oldcolo.UUCP (Dave Hughes) writes: >>How else, short of a reboot, can I kill a process on a port that >>kill -9 won't kill? > >If the process is sleeping waiting for i/o (the `ps -l' PRI value will >be 20 or less), you can not kill it. The only answer is to reboot. True answer in the first part. One thing should be added: Many drivers sleep non interuptable, if they are waiting for flow control to become active (ie, if output is stopped by hardware- or XOFF-protocoll). A typical example is a printer, that has run out of paper. If you switch the printer off now (because the page printed accidentially was the last one you wanted to be printed), the printing process might still hang, waiting for XON. If you kill the process, it will not go away. Assuming your printer sends XON right after power on, the hung (and allready killed) process vanishes right after you switch your printer on again. BTW: If the device was not opened in exclusive mode, then you can flush the queue with an appropriate 'ioctl'-call from another process (executing a small program, not to difficult to write in C). In most cases this will also wake up (and if allready killed, also terminate) the hung process, because after flushing the queue there is no reason for the driver to wait for flow control to become active. -- <<< MW -- email: see header -- voice: 49-(0)6151-6 56 83 >>>
erc@khijol.UUCP (Edwin R. Carp) (12/19/89)
In article <[628]unix@oldcolo.UUCP> dave@oldcolo.UUCP (Dave Hughes) writes: >How else, short of a reboot, can I kill a process on a port that >kill -9 won't kill? > What's happening is that the system is hanging on the exit() call. exit() calls close() to close all of the remaining open files. When it gets to the modem, it can't close the port (or, more correctly, it hangs closing the port) because it's waiting for some sort of signal from the modem (usually DSR, CTS, or CD to drop). Make sure that DSR drops when the party hangs up, etc. --------------------------- discard all after this line ----------------------- Ed Carp N7EKG/5 (28.3-28.5) ...!attctc!puzzle!khijol!erc (home) (512) 832-5884 Snail Mail: 2000 Cedar Bend Dr., #335, Austin, TX 78758 [Disclaimer: The information contained in this message is soley for informa- tional purposes only. Use at your own risk. No warranty expressed or implied.] "You may think you're smart, Pierce, but you're DUMB! Real DUMB! But, you've met your match in ME!" - Col. Flagg "Good tea. Nice house." -- Worf
dave@oldcolo.UUCP (Dave Hughes) (12/20/89)
This must be a more general problem than I thought. Will post solutions to the net when I get one.....I have had many private e-mails that they have the same problem. SCO????
rogerk@sco.COM (Roger Knopf 5502) (12/23/89)
In article <[628.1]unix;1@oldcolo.UUCP> dave@oldcolo.UUCP (Dave Hughes) writes: >This must be a more general problem than I thought. Will post >solutions to the net when I get one.....I have had many private e-mails >that they have the same problem. SCO???? I missed the earlier postings, so this is a shot in the dark based on the header line.... Kernel routines which run at priority 24 or lower (see the PRI column when you run ps -el) are not interruptible by a signal. If you get into one of these routines and can't get out (bug or HW failure, its never _normal_), the process will be unkillable by any signal. More details can be supplied for those interested. Roger Knopf SCO Consulting Services {sun,uunet}!sco!rogerk or rogerk@sco.com disclaimer: the usual stuff....
cpcahil@virtech.uucp (Conor P. Cahill) (12/23/89)
In article <822@scorn.sco.COM>, rogerk@sco.COM (Roger Knopf 5502) writes: > signal. If you get into one of these routines and can't get out (bug > or HW failure, its never _normal_), the process will be unkillable > by any signal. More details can be supplied for those interested. Just a little bit of nit-picking. A very normal way of getting into this situation is to go to a terminal and cat /etc/termcap. Once the output starts, do a CTRL-S. after a few seconds (once the output buffering has filled up) the cat process will no longer be killable. However, once a CTRL-Q is typed at the terminal, any signals sent to the cat process will be delivered. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
soup@penrij.LS.COM (John Campbell) (12/25/89)
In article <1989Dec23.031934.1395@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) writes: > In article <822@scorn.sco.COM>, rogerk@sco.COM (Roger Knopf 5502) writes: > > signal. If you get into one of these routines and can't get out (bug > > or HW failure, its never _normal_), the process will be unkillable > > by any signal. More details can be supplied for those interested. > A very normal way of getting into this situation is to go to a > terminal and cat /etc/termcap. Once the output starts, do a CTRL-S. > after a few seconds (once the output buffering has filled up) the cat > process will no longer be killable. However, once a CTRL-Q is typed > at the terminal, any signals sent to the cat process will be delivered. I ran across this back 6 years ago on an Intel 286/310 w/ 544 _and_ 188 cards. I was told that it was caused by a "race condition" in the serial port handler, that it can't close the session until it flushed the buffers- which it can't do without being released by flow control. I had a lot of fun working around this; I did eventually do it by "cheating"- we were connected to a serial port LAN (Ungermann-Bass Net/One) so a "daemon" activity looked for a locked process and would disconnect his session, connect to him, receive ALL of the traffic, then tell the process to restart after releaseing the net session. This trick worked. It turns out that Intel claims to have corrected the problem in XENIX R3.4- which I have installed but no longer in a position to test. Of course, I don't have the right version of firmware for my 544 cards, but... what the hell... Now for a real laugh: On the Convergent SPC they had a nice bug in the LP driver (since claimed as fixed) which, when the printer ran out of paper (or went off-line) in the middle of a print job would LOCK UP THE WHOLE SYSTEM. The solution: re-load the printer with paper (if needed) and place it on-line. The system would pick up where it left off. This was for the parallel port printer. Since the SPC200 is the Unisys 6000/50 (and SYSINU never has the current OS version) I wonder if the bug/feature/whatever still lives? -- John R. Campbell (soup@penrij.LS.COM) "In /dev/null no one can hear you scream"