mferrare@physics.adelaide.edu.au (Mark Ferraretto) (03/24/91)
How do I kill this process? root 6585 0.0 0.0 48 0 je S 15:47 0:00 <exiting> I've already tried kill -[1-9] 6585 especially kill -9 6585 The process used to be a getty. I'm running SunOS4.0.3 on a Sun 4/280. Terminal is connected to ALMII Board
mike@sharebase.com (Mike Ubell) (03/28/91)
In article <2150@brchh104.bnr.ca> you write: >How do I kill this process? > >root 6585 0.0 0.0 48 0 je S 15:47 0:00 <exiting> Reboot! This looks like a flow of control problem where the port frezes waiting for the output to drain but it has recieved an x-off (or cts has dropped, if enabled). There is a patch: 100194-02 that seems to fix this. Unfortunately it seems to have the side effect that the local designation in /etc/ttytype does not work on the higher numbered alm ports. If this was a tip it could be the cts problem in which case you cna change your remote entry to remove the "hf" designation, if present. If you want to try to free the port without rebooting you can connect a terminal with a null modem at the proper baud rate (if you know what it is) and type a CNTR-Q (or assert the cts line, as apropriate).
dplatt@apple.com (Dave Platt) (04/02/91)
In article <2150@brchh104.bnr.ca> mferrare@physics.adelaide.edu.au (Mark Ferraretto) writes: >How do I kill this process? > >root 6585 0.0 0.0 48 0 je S 15:47 0:00 <exiting> > >I've already tried >kill -[1-9] 6585 >especially kill -9 6585 > >The process used to be a getty. >I'm running SunOS4.0.3 on a Sun 4/280. >Terminal is connected to ALMII Board Welcome to the "Dead gettys society", Mark. I've seen hung getty processes of this sort on 4.0.3 and 4.1.1, on both an ALM-II and on CPU serial ports, on a 4/280, 3/60, a Sparc-1. Quite a few other people have seen this problem as well. I never saw it on SunOS 3.5, and so I suspect that the problem was introduced with SunOS 4.0. The dead gettys seem to crop up when an outbound phone call (e.g. uucico) closes the secondary aspect of a dual-direction serial port (e.g. the call was made on /dev/cua, and there was a getty camped on /dev/ttya). Most of the people who have mentioned this problem seem to be running Telebit modems in PEP mode. I don't know whether the problem is related to the Telebits, or whether the Telebits are simply the most popular modem in use on bidirectional ports. My suspicion is as follows: when uucico terminates, it closes the secondary port descriptor. This causes DTR to be deasserted for a second or so. The Telebit modems take a second or so to deassert the CD (carrier detect) line after they see DTR go away... and in some cases, DTR comes back up before CD is deasserted.. I believe that the hung getty may appear if the getty process is allowed to open the port after DTR comes back up and before the modem drops CD. This allows the getty to start configuring the port... and if CD then drops before the configuration is completed, one of getty's ioctl() calls hangs up somehow. I've installed the latest Sun serial-port patch (100225-02), which was apparently supposed to fix some hung-serial-port problems. It does not appear to have eliminated the hung-getty problem... I had one occur yesterday. Oh... per your original question... when a really-hung getty process shows up, the only way I know of to kill the process and get the port back into use is to reboot the machine. The only way I know of to entirely avoid the problem is to use your modems for dialin or dialout, but not both. Dave Platt VOICE: (415) 813-8917 UUCP: ...apple!ntg!dplatt USNAIL: New Technologies Group Inc. 2468 Embarcardero Way, Palo Alto CA 94303
pickles@mpr.ca (Clive Pickles) (04/02/91)
In article <2226@brchh104.bnr.ca> mike@sharebase.com (Mike Ubell) writes: >In article <2150@brchh104.bnr.ca> you write: > >>How do I kill this process? >> >>root 6585 0.0 0.0 48 0 je S 15:47 0:00 <exiting> > >Reboot! NOT NECESSARY! >This looks like a flow control problem where the port frezes waiting >for the output to drain but it has recieved an x-off (or cts has dropped, >if enabled). There is a patch: 100194-02 that seems to fix this. ***deleted stuff here >If you want to try to free the port without rebooting you can connect a >terminal with a null modem at the proper baud rate (if you know what it >is) and type a CNTR-Q (or assert the cts line, as apropriate). An EASIER way of doing this is to make yourself root, then put a trace on this process. On my 4.0.3 system, this "wakes the process up" and causes it to finish exiting (and also cleans up any defunct processes it may have spawned). The process should exit almost immediately. But I agree with Mike...you should really get the patch. = Clive Pickles - Systems Administrator MPR Teltech Ltd. (Ottawa) = = Phone: (613) 787-4159 ------------------ E-mail: pickles@mpr.ca =