Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!munnari.oz.au!sirius.ucs.adelaide.edu.au!chook.ua.oz
From: francis@chook.ua.oz (Francis Vaughan)
Newsgroups: comp.sys.encore
Subject: Re: telnet/rlogin "bouncing"
Message-ID: <763@sirius.ucs.adelaide.edu.au>
Date: 9 Feb 90 01:57:58 GMT
References: <1052@thor.wright.EDU>
Sender: news@ucs.adelaide.edu.au
Lines: 53

From article <1052@thor.wright.EDU>, by dcourte@eve.wright.edu (Dale Courte):
> 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.

... plus explanation

> -Dale Courte

We have experienced the same problem from the word go, two years ago on our
Multimax running UMAX. We also reported the problem. Since most of our
systems hackers use Suns we found it nessesary to have a terminal attached
to an annex, ready all the time soley to enable us to clear the problem via
the "call" protocol. The system mangers would always have the line
echo `tty`
in their .logins so they could immeadiately identify the blocking ptty.
Then log in via "call" on the annex line and shoot the process attached to
the ptty. We never killed a real job, it was always just one process still
attached to the ptty (other then getty) owned by an ordinary user. It gets
to be quite fun when the ptty that blocks up is ptty0. Occasionaly people
could still login, that would happen when two people logged in together and
the lucky one got allocated to the next ptty after the blocking one.

The logout happens when the starting shell fires up and attaches itself to
the ptty. For some reason the first thing it reads is an EOF and thats it.

We have had a lot of trouble with processes hanging around, or not
correctly dieing. A lot of the new students (or worse those that had been
using VMS before) would type control-Z to stop compilations and other
things (Remember ^Z is EOF on VMS). They would then just hit break on the
annex line and think they were logged out. A kill command on the annex (or
a timeout) would send SIGHUP to all the processes. Instead of quietly dieing
we found some (in particular programs written in Pascal) would go nuts.
They would go into an infinite loop and start to allocate lots of memory.
Eventually we were forced to write a deamon to kill these off. The best
explanation we could thing of was that the signal handler under UMAX was
broken. We know it is one part that Encore had rewritten.
A lot of this has calmed down now, but this may be because we have better
behaved students, rather than Encore having fixed the problems.

Dept of Computer Science                        Francis Vaughan
Adelaide University                             francis@cs.ua.oz.au
South Australia