Path: utzoo!utgpu!cunews!bnrgate!brtph3!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request From: ntg!dplatt@apple.com (Dave Platt) Newsgroups: comp.sys.sun Subject: Re: How do I kill this? Keywords: Miscellaneous Message-ID: <2307@brchh104.bnr.ca> Date: 2 Apr 91 15:00:00 GMT Sender: news@brchh104.bnr.ca Organization: Sun-Spots Lines: 51 Approved: Sun-Spots@rice.edu X-Original-Date: Wed, 27 Mar 91 15:18:20 PST X-Refs: Original: v10n65, Replies: v10n69 X-Sun-Spots-Digest: Volume 10, Issue 75, message 3 X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu 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 > >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