Very Computer

Any ideas as to why?

My understanding is that when unix (AIX) detects (somehow) the client
dying, child processes of are supposed to get a HUP signal and the
default action is to exit. I don't believe the app is ignoring the HUP
signal, because this also happens outside of the app. The .login that
invokes the app, prompts for a number, before launching the app. (The
app is not exec'd).

The .login doesn't do anything special about dealing with the HUP
signal. It prompts for a number, then runs another shell script which
inturn starts the app. If telnet dies when the .login is sitting
waiting for input, the tcsh doesn't die.

All this hinders the app from getting restarted after the client
restablishes a new telnet session.

My platform is AIX, app written in C, tcsh shell. The client is usually
a Telxon RF unit (wireless Radio Frequency) over ethernet. The RF unit
reports that it has lost it's network connection and will eventually
get rebooted and acquire a new telnet session, usually on a different
psuedo terminal device.

We've had to write a workaround to get the process killed from another
telnet session.

Any ideas and suggestions would be appreciated.

Thanks, Zoran.

Sent via Deja.com http://www.deja.com/
Before you buy.

On AIX you can adjust the keepalive idle interval (the amount of time a
connection has no data flowing before the system sends the first
keepalive packet) using the no command:

  no -o tcp_keepidle=<new_val>

The value is in 500ms units, and it defaults to 14400 (120 minutes).

              -----------------------------------

The Kernel Group, Inc.                         http://www.veryComputer.com/
ZeroFault Memory De* finds memory leaks and bugs in minutes!

Walter

The process might ignore SIGHUP, thus it would continue after telnet
itself has gone.

'stty clocal' might cause the SIGHUP not to be sent in the first place.

Villy

But behaviour doesn't seem to occur when the Telxon RF units are
involved.

BTW, Peter if you're still listening, what is a RST? Can this be read
about in Richard Stevens Network Programming Book(s)?

Zoran.

These were both on Teklogix based RF devices. On the former, occasionally we
had processes hang on the system, but this was due to apps which did not
close correctly. The developers fixed this. On the later example, again the
application occassionally failed to close correctly. We never did get that
fixed, rather created a method for killing these off when we noticed them.

-JAZZ

--
John Jaszczak
Romac International
Assigned to: Harmonic Systems, Inc.

612-321-4139

Our client-server application uses the telnet protocol. What happens
is that if the client application (MS Windows) terminates in a certain way,
i.e. the user kills the client by clicking on the "close window" button,
the server side starts running in a tight read loop that uses all available
CPU. I have verified this by attaching a de* to the server process
and it is always in a loop executing read system calls.  The same thing
happens if the client crashes.  However, if the client is closed "cleanly"
by the user clicking on a "close application" button inside the application
window then the server side process also exits normally.  This seems to
suggest that the problem is related to the socket connection not being
explicitly closed by the client.

I tried the suggested solution of reducing the TCP Keep Alive timeout.
Not surprisingly it had no effect.  Not surprising because these runaway
processes have been observed to run for days until explicitly killed.

--


                     |  http://www.veryComputer.com/~mayd  |

/*
     * Spin, waiting for a response from the DO ECHO.  However,
     * some REALLY DUMB telnets out there might not respond
     * to the DO ECHO.  So, we spin looking for NAWS, (most dumb
     * telnets so far seem to respond with WONT for a DO that
     * they don't understand...) because by the time we get the
     * response, it will already have processed the DO ECHO.
     * Kludge upon kludge.
     */
    while (his_will_wont_is_changing(TELOPT_NAWS)) {
        ttloop();
    }

From the telnetd manpage:

BUGS: The source code is not comprehensible.

If you look at telnetd sourcecode yourself, you'll see that it makes a lot
assumptions on what clients might send or not. The whole code is a big mess
and the above example will loop forever if the telnet client doesn't send NAWS.
We really can't blame the writer of the code though, because he's trying his
best to work around all the crappy telnet implementations (such as windows
telnet). If you really want to fix that problem, you'll have to rewrite telnetd.

--
Sorisor