seth@sirius.ctr.columbia.edu (Seth Robertson) (03/29/89)
Hello. I have been having this trouble whereby if a person rlogin/telnets to various machines, when they type, all of their characters get translated into ^Ds. I personally use ksh, and this does not happen to me. However, when su to root (which uses csh) the characters again are translated. The translation also occurs if I use `Mail`. The problem can be avoided (for me) if I rlogin to the same machine (getting a new pseudo-tty #). This seems to happen (with no apparent cause, on a fairly frequent bases on the first rlogin session (but not always ttyp0) Has anybody else had this trouble? Any advice? I am running 4.0 -Seth seth@ctr.columbia.edu
guy@uunet.uu.net (Guy Harris) (04/21/89)
>I have been having this trouble whereby if a person rlogin/telnets to >various machines, when they type, all of their characters get translated >into ^Ds. Once more, with feeling: this sounds like "half-remote" mode, described in a previous posting. Said posting contains a program to unjam pseudo-ttys in this mode, and a suggestion about how to fix it if you have source. The suggestion was also forwarded to Sun; it should be fixed in 4.1, and possibly in some dot-dot release.
dougf@elroy.jpl.nasa.gov (Doug Freyburger) (04/22/89)
seth@sirius.ctr.columbia.edu (Seth Robertson) writes: >I have been having this trouble whereby if a person rlogin/telnets to >various machines, when they type, all of their characters get translated >into ^Ds... > seth@ctr.columbia.edu `ps' will show a process running in the background attached to the pty. The workaround is to have someone consume the pty with a window on their workstation. We have several machines that are used as general purpose workhorses; I usually have a couple windows holding down ptys consumed by background jobs. dougf@wega.caltech.edu Douglas J Freyburger Caltech 206-49 Pasadena, CA 91125 (818)356-2913
dav@hplabs.hp.com (David L. Markowitz) (04/25/89)
seth@sirius.ctr.columbia.edu (Seth Robertson) writes: > I have been having this trouble whereby if a person rlogin/telnets to > various machines, when they type, all of their characters get translated > into ^Ds. I personally use ksh, and this does not happen to me. However, > when su to root (which uses csh) the characters again are translated. The > translation also occurs if I use `Mail`. > > The problem can be avoided (for me) if I rlogin to the same machine > (getting a new pseudo-tty #). This seems to happen (with no apparent > cause, on a fairly frequent bases on the first rlogin session (but not > always ttyp0) > > Has anybody else had this trouble? Any advice? I am running 4.0 This has to qualify as one of the most frequently asked questions on here. This problem has existed for a long time, and is still in 4.0 and 4.0.1. Are you listening, Sun? The trigger of this bug is a background process. Whenever a process is put in the background from a pty without redirecting its standard input, and the pty is then closed (remote user logs out, window user exits from that window), the O.S. is supposed to reconnect the input of that process to the null device. For some reason (anyone know why?) it screws up the pty in so doing such that any new process which tries to use it is marked the same way (but only after a character is typed). This effect goes away when the process exits. The astute observer will note that the effect of this is not quite to "translate all chars into ^D", but instead to translate any char into an infinite sequence of ^D's. Try setting ignoreeof in the .cshrc of a csh and then run it on such a pty. You will see lots of 'Use "exit" to leave csh.' messages after typing one character. Your choice of work-arounds: 1. Always redirect input of background jobs being run on pty's that will be closed before they are done (I know, try teaching that to the freshmen). 2. Kill the offending process (that'll teach that frosh!) 3. Open a window/rlogin, open another, use the second one. You may kill the first if you wish, but this will allow that pty to annoy some other user who is less intelligent and experienced than you are. (Closing the window is fine, just don't type at it). 4. Everybody call (800) USA-4SUN and tell them we won't buy any more hardware/software/maintenance until they fix this bug. Oh, and picket the April 13th announcement bash too. I usually use #2. -- David L. Markowitz Rockwell International ...!sun!sunkist!arcturus!dav dav@arcturus.UUCP The above opinions are merely that, and only mine.
pratt@triangle.com (05/06/89)
In Sun-Spots v7n244 David L. Markowitz writes
Your choice of work-arounds:
...
2. Kill the offending process (that'll teach that frosh!)
I used to run into this problem a lot, always with "perfmeter -v page" as
the offending background process. I stopped using that particular
perfmeter four months ago and have not seen the ^D problem since.
Vaughan Pratt
pratt@triangle.comcudcv@cu.warwick.ac.uk (Rob McMahon) (05/06/89)
felix!arcturus!dav@hplabs.hp.com (David L. Markowitz) writes: |Your choice of work-arounds: |... | 2. Kill the offending process (that'll teach that frosh!) I've seen pty's in this state after the process has finished, so I don't think 2 always works. It can also manifest itself as a complete inability to rlogin to a machine (login sees ^D and goes away again). My solution is 5. cd somewhere innocuous, type `script', then `reset', `exit', remove the typescript file, and your pty is fixed. Works for me, no guarantees. On a machine with lots of people logging in and out it's sometimes useful to nest the scripts, doing a `tty' in each one, until you get to the line that's jammed. Rob -- UUCP: ...!mcvax!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick ARPA: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England