Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!sri-spam!sri-unix!hplabs!tektronix!penguin!richl From: richl@penguin.uss.tek.com (Rick Lindsley) Newsgroups: net.unix-wizards Subject: Re: Problems with rlogin Message-ID: <9041@tektronix.UUCP> Date: Wed, 29-Oct-86 15:40:20 EST Article-I.D.: tektroni.9041 Posted: Wed Oct 29 15:40:20 1986 Date-Received: Thu, 30-Oct-86 22:41:31 EST References: <2460@phri.UUCP> <1904@mcc-pp.UUCP> <332@esl.UUCP> Sender: richl@tektronix.UUCP Reply-To: richl@penguin.uss.tek.com (Rick Lindsley) Organization: Tektronix, Inc., Beaverton, OR. Lines: 82 In article <332@esl.UUCP> mac@esl.UUCP (Mike McNamara) writes: > User tty login@ idle JCPU PCPU what > amp p3board 2:13pm 1:43 1:32 16 -csh > amp pty2 4:38pm238:48 123:92 123:21 - 7%4( %^ > mac ttyp3 4:35pm 6:44 4:35 w > > A reboot cleans these up. Until a reboot, users attempting to vi get wierd > window sizes (indeed, anything accessing window sizes over ptys gets strange > data -- this includes people logged in over ethernet.) > > Any one know a better fix than L1 A ( or shutdown -r 5 Resetting Sun :-)? Yes, I think so. I spent the better part of a day tracking this down. I'm running 3.0 on a 3/50. The same bug exists under 3.0 on a 3/160 too. 3.0 has kernel structures for window sizes. Of course. These are settable via an ioctl. Termcap has been altered to look at these sizes. If they are non-zero, they apparently REPLACE the li: and co: entries in the termcap entry. Normally, this makes perfect sense. Unless ... unless you aren't running in a resizeable window. Something takes care to set these to 0 when you start. However, this DOESN'T happen if there is already a process running on the pty. Judging from this, I'd say the kernel, upon final close in the tty driver, is in charge of resetting these to 0. I can think of many situations where this makes perfect sense, but nevertheless it is the cause of the bug. The 'w' output you gave (and the amazing amount of cpu time) indicates there is probably another process still running on that terminal. Did you do a "ps atp1"? That will show all the processes running on ttyp1, and might verify that this is the case. Repeat it by making a window. Run the program below, tst, to show the window size. Do "sleep 600 &" and close the window. Now rlogin from another host. Check to see that you have the right tty. Run tst again, and you'll see the "window size" hasn't changed. Unless you are running on a terminal which happens to be the same size as your window was, your termcap won't work. Tset does NOT reset the window size, either. (I can see arguments in favor of this behavior also.) It might be reasonable for stty to report (and set) these sizes. Perhaps rlogind should do this. Doesn't matter; the fix is Sun's to ponder, not mine. I couldn't find a Sun program which allowed me to change the window size, so I wrote tst2. If you run tst2, below, you'll find your troubles go away, if they are from this problem. No complaints about style please; I admit they are quick and dirty! Embellish at will. tst: ----- #include main() { struct ttysize size; if (ioctl(0,TIOCGSIZE,&size) < 0) perror("ioctl"); else printf("Size is %d, %d\n", size.ts_lines, size.ts_cols); } ----- tst2: ----- #include main() { struct ttysize size; size.ts_lines = 0; size.ts_cols = 0; if (ioctl(0,TIOCSSIZE,&size) < 0) perror("ioctl"); } ----- Rick Lindsley