Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!ucbvax!ucsd!ucsdhub!hp-sdd!ncr-sd!ncrlnk!wright!eve!dcourte From: dcourte@eve.wright.edu (Dale Courte) Newsgroups: comp.sys.encore Subject: telnet/rlogin "bouncing" Message-ID: <1052@thor.wright.EDU> Date: 6 Feb 90 21:50:04 GMT Sender: news@wright.EDU Reply-To: dcourte@eve.wright.edu (Dale Courte) Organization: Wright State University, University Computing Services Lines: 93 Have any of you experienced the following when attempting to telnet to your Multimax?: Trying... Connected to xxxxxx Escape character is '^]'. Umax 4.2 (xxxxxx) Login: Connection closed by foreign host. The "connection closed" comes up immediately after the word login appears. It is impossible to log in. If you rlogin, the login is accomplished (provided the machine you are rloging in from is in your .rhosts), the message of the day is printed, the system prompt appears, then BANG, you get "connection closed". Only a "call" from an annex server will get you logged in at this point. Most of our users on campus don't use an annex. Here's what I have found through countless encounters with this very annoying problem: 1) It is the next available psuedoterminal which seems to be the problem. For instance, if the problem exists and I do a 'w' and see: 3:54pm up 1 day, 18:50, 13 users, load average: 1.25 1.93 2.67 User tty login@ idle JCPU PCPU what cse4a031 ttyp0 11:11am 2:03 1:41 ksh cse4a028 ttyp1 3:49pm 7 2 ksh cse1001 ttyp3 3:54pm 2 ksh cse6028 ttyp4 3:51pm 11 2 ksh the problem will persist until either the user on ttyp0 or ttyp1 logs off. Then another user can log in. Then the problem returns. I assumed from this behavior that the problem was therefore with the psuedoterminal ttyp2 (or whatever - it is not always the same one). 2) If I peruse the output of 'ps -aux' when the problem occurs, I can always find a process "hanging around" assigned to that psuedoterminal. Sometimes multiple processes, other times just the telnetd or rlogind belonging to root. 3) If the processes assigned to the psuedoterminal are killed (which, of course, is not always advisable in an environment where faculty research jobs are often running in the background) the problem goes away. 4) The people at Encore (at least the _old_ Encore) never seemed to believe my story. I reported it three times, then just decided to sit back and wait for the "imminent" arrival of Umax 4.3. That was at least 6 months ago. Meanwhile, I just spend a lot of time waiting for the phone to ring and for someone to say "There's a psuedoterminal hosed up again. Can you fix it?" In any of you have seen this problem, please let me know if: 1) You have found a solution to the problem? 2) You would be willing to corroborate my story if I take it to the _new_ Encore? 3) If you are a beta site for Umax 4.3, has the problem been fixed in 4.3? Speaking of the _new_ Encore, I would also like to know what experiences any of you have had with the new organization. I am intersted because I lost a sales rep, was never informed of the fact until I posted a minor flame on the net, was then contacted by a very apologetic person who said he was "temporarily" my rep. I then heard nothing more for quite a long time. Next, the person who does our accounting here asked me for our rep's name. I gave him this "temporary" rep's name. He called, only to find that we had yet another rep and had once again not been informed. Let me make it clear that I am _not_ trying to start a flame-fest here. I merely want to know if my experiences are unique. I am not unhappy with our Multimax. There are several problems I have contacted (_old_) Encore about and have gotten prompt service. The Multimax hardware has been _very_ reliable, and hardware service has always been prompt. As mentioned above, I have had almost no contact with the new Encore and that bothers me, as does the one nagging software problem described above. Let me know if you have any input which might help me. Thank You. -Dale Courte Wright State University CSNET: dcourte@eve.wright.edu BITNET: dcourte@wsu