Telnet dies but process does NOT, why not?

Telnet dies but process does NOT, why not?

Post by zmar.. » Tue, 05 Oct 1999 04:00:00



I have a character based unix application that is launched by a
users .login script. We're noticing that if the app is waiting for the
user to enter data and IF the telnet client dies, the process that was
waiting for input, doesn't die.

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.

 
 
 

Telnet dies but process does NOT, why not?

Post by Peter Jeff » Tue, 05 Oct 1999 04:00:00



> I have a character based unix application that is launched by a
> users .login script. We're noticing that if the app is waiting for the
> user to enter data and IF the telnet client dies, the process that was
> waiting for input, doesn't die.

If the client goes away and the server isn't trying to send data to it,
then it will keep the TCP connection open forever or until TCP keepalive
closes the connection (assuming the client doesn't respond to the
keepalive packets, or sends a RST if it has rebooted or something).

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!

 
 
 

Telnet dies but process does NOT, why not?

Post by Walter Hofman » Wed, 06 Oct 1999 04:00:00



> I have a character based unix application that is launched by a
> users .login script. We're noticing that if the app is waiting for the
> user to enter data and IF the telnet client dies, the process that was
> waiting for input, doesn't die.

> Any ideas as to why?

AFAIK HUP gets sent to the program iff its controlling terminal dies.
You should be able to check the controlling terminal with the ps
command. Is is the same like, say, the shell? Or does the program change
it?

Walter

 
 
 

Telnet dies but process does NOT, why not?

Post by Villy Kru » Thu, 07 Oct 1999 04:00:00





>> I have a character based unix application that is launched by a
>> users .login script. We're noticing that if the app is waiting for the
>> user to enter data and IF the telnet client dies, the process that was
>> waiting for input, doesn't die.
>> Any ideas as to why?
>AFAIK HUP gets sent to the program iff its controlling terminal dies.
>You should be able to check the controlling terminal with the ps
>command. Is is the same like, say, the shell? Or does the program change
>it?

Two things:

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

 
 
 

Telnet dies but process does NOT, why not?

Post by zmar.. » Thu, 07 Oct 1999 04:00:00


Thank you all for your replies, but Peter's seems to fit our situation
best. I've tested the theory of the HUP being ignored by using the
telnet client on my desktop PC (and laptop). When I abruptly exit my
telnet session by clicking on the X (upper right corner of window), all
processes run by that telnet session go away instantly by themselves.

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.




> > I have a character based unix application that is launched by a
> > users .login script. We're noticing that if the app is waiting for
the
> > user to enter data and IF the telnet client dies, the process that
was
> > waiting for input, doesn't die.

> If the client goes away and the server isn't trying to send data to
it,
> then it will keep the TCP connection open forever or until TCP
keepalive
> closes the connection (assuming the client doesn't respond to the
> keepalive packets, or sends a RST if it has rebooted or something).

> 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!

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

Telnet dies but process does NOT, why not?

Post by John Jaszcza » Fri, 08 Oct 1999 04:00:00


I have seen RF terminals access RS6k's using two different methods.
1) The RF device telnets into the rs6k and based on its terminal type, it
opens a RF specific pty (formatted for the smaller screen). It acts exactly
like a standard pty.
2) The RF device connects to the RFbase which using proprietary software
opens a connection to the rs6k. Proprietary software is run on the rs6k
which opens an session specifically for the terminal that connected. i.e.
RFterminal01 has a process on the RS6k called RFprocess01. If the
RFterminal01 did not close in an orderly manner, then the RFprocess may
linger on the system.

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


>Thank you all for your replies, but Peter's seems to fit our situation
>best. I've tested the theory of the HUP being ignored by using the
>telnet client on my desktop PC (and laptop). When I abruptly exit my
>telnet session by clicking on the X (upper right corner of window), all
>processes run by that telnet session go away instantly by themselves.

>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.




>> > I have a character based unix application that is launched by a
>> > users .login script. We're noticing that if the app is waiting for
>the
>> > user to enter data and IF the telnet client dies, the process that
>was
>> > waiting for input, doesn't die.

>> If the client goes away and the server isn't trying to send data to
>it,
>> then it will keep the TCP connection open forever or until TCP
>keepalive
>> closes the connection (assuming the client doesn't respond to the
>> keepalive packets, or sends a RST if it has rebooted or something).

>> 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!

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

 
 
 

Telnet dies but process does NOT, why not?

Post by David M » Sun, 24 Oct 1999 04:00:00





>> I have a character based unix application that is launched by a
>> users .login script. We're noticing that if the app is waiting for the
>> user to enter data and IF the telnet client dies, the process that was
>> waiting for input, doesn't die.

> If the client goes away and the server isn't trying to send data to it,
> then it will keep the TCP connection open forever or until TCP keepalive
> closes the connection (assuming the client doesn't respond to the
> keepalive packets, or sends a RST if it has rebooted or something).

> 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).

I have a problem very like this one.  The strange thing is I do not believe
the problem existed on our machine before installation of an IBM patch for
AIX 4.1.5 Y2K compliance.

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  |

 
 
 

Telnet dies but process does NOT, why not?

Post by Soriso » Sun, 24 Oct 1999 04:00:00



> 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.

From the telnetd source:

/*
     * 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

 
 
 

1. child processes not dying with parent process??

Hello all,

I have an application program which spawns a few child processes. This
application program has to start from a shell script in background mode.
When I kill (kill -9 <pid> from a login shell) the parent process, the
child processes remain active, and have to be killed individually.
Doesn't the parent issue a SIGKILL of some sort to all its children??

At the moment, the parent process has a SA_NOCLDWAIT set so that when its
child process dies, they don't leave <defunc> processes lying around.
That is the only signal-related code I have in the code.

Any info is greatly appreciated...please e-mail as I don't read this
newsgroup.

Thanks in advance,


Level 1,
30, Kings Park Road,
West Perth, 6005,
Western Australia.

2. format.dat entry for Fujitsu-M2654SA

3. PROCESS:kerbd: could not be located + PROCESS:lpNet: could not be located

4. Buying a alpha/Linux

5. How to not have process number / 'done' line for background process?

6. PPP dialing constantly

7. serial processes not dying with hangup (reliably)

8. Loader gets SIGSEGV during RH 7.3 install

9. ProFTPd: child process not dying

10. processes not dying on tty

11. rsh process not dying.

12. JVM processes not dying (Linux Blackdown 1.3.1)

13. Need help with SCO: the process that would not die.