in.telnetd problem (was Re: Messages from aa012) (fwd)

Date: Sat, 19 Apr 1997 10:49:25 -0300
From: Gerard MacNeil <macneil@chebucto.ns.ca>
To: CSuite Technical Reports <csuite-tech@chebucto.ns.ca>
cc: techteam@wwhcn.cnet.windsor.ns.ca
Precedence: bulk

next message in archive
no next message in thread
previous message in archive
Index of Subjects


So it appears network latency is the root cause of the problem.  

As a strategy, I have been thinking that if 'pkiller' would detect a
"lynx" process with no controlling terminal, it could kill it.

Is there a downside to this type of action?  Can there be a lynx process
legitimately running under CSuite without a controlling terminal?

Gerard MacNeil, P. Eng.

---------- Forwarded message ----------
Date: Sat, 19 Apr 1997 10:34:12 -0300
From: Larry Brinton <brinton@glinx.com>
To: Gerard MacNeil <macneil@wwhcn.cnet.windsor.ns.ca>
Subject: Re: in.telnetd problem (was Re: Messages from aa012)

Gerard,

I have been killing runaway processes (mostly lynx/bash) when I have
noticed wwhcn CPU usage running high. This same problem occures when
"dialog" loses it's controlling terminal. Both dialog and lynx use ncurses
which is where the logic must be. If in.telnetd dies unexpectedly, it
obviously cannot cleanup after itself. I don't know why telnetd dies, it's
the one that comes with all 2.0.x Linuxes. I've seen this happen in all
versions of Linux. It has to be some kind of timeout caused by latency
between the client and server, I don't have the source code. If Chebucto
has a Linux box, they should be experiencing the same symptoms. Try
running telnet from a heavily loaded network like iStar to duplicate the
problem.

PS: Within the next few weeks, Global Linx will have a leased T1 line to
UUNET's backbone in Halifax, and abandoning the Frame Relay T1 to UUNET in
Toronto. :-) The 1200 MTU on the FR in Toronto will no longer create grief
for us, as it has for the past 18 months.

..Larry
				 ----------------------
Systems/Networking Specialist   |   support@glinx.com  |
Global Linx Internet, Inc.      |     Serving the      |
     (902) 678-1900             | Annapolis Valley, NS |
				 ----------------------

On Thu, 17 Apr 1997, Gerard MacNeil wrote:

> 
> > On Sat, 12 Apr 1997, Patricia Gould-Thorpe wrote:
> > 
> > > He seems to have registered as aa012, which is good, since that is the 
> > > next userid available. He also seems to have found a bug in the ip 
> > > application process.
> 
> and
> 
> > > I received about 100 messages from ip-admin, each one bigger than the 
> > > last. My apologies to everyone else who got them. I think you should 
> > > delete all these messages before you try to do anything else.
> > 
> 
> aa012 submitted an IP application for "friends" and the 'in.telnetd' process 
> died (unknown reason).  The processes for CSuite "shell" and "lynx" lost 
> their controlling terminal, so "CS_ROOT/tq/idled" did not find them.
> 
> The CGI script submit (2nd part with the address, etc) was the active 
> process when "in.telnetd" died.  This script appends the aditional data 
> to the IP database record, and sends mail about the IP application to IP 
> Administration.
> 
> Without the parent "in.telnetd", the Lynx process re-runs over and over 
> and, in this case, increased the size of the mail message on each cycle.  
> The havoc experienced ensued.
> 
> Unless some other action had been taken, the 'cron' program "pkiller" 
> eventually came into action.  "pkiller" checks for runaway "Lynx" and 
> "Pine" programs that have consumed more than 10 minutes of CPU processing 
> time.  I assume this occurred, finally terminating the misadventure.
> 
> There are several issues to be contemplated:
> 1. CCN has been "lucky", as no runaway lynx process has been sending mail so 
> the probem had not been experienced.
> 2. On a low usage system such as WWHCN, the 10 minute delay for "pkiller" 
> appears excessive.  For a high usage system, an appropriate limit is unknown.
> 3. A more robust method for detecting runaway processes is needed, 
> perhaps by including the intended functionality of "pkiller" with "idled".
> 
> 
> Gerard MacNeil, P. Eng.
> 




next message in archive
no next message in thread
previous message in archive
Index of Subjects