How to kill lost telnet sessions?

[Dan Rosen]

We have users telnet to our system to use our database. On occasion, they will have their telnet session ended from the client side for a variety of reasons (computer crash, loss of dialup, VPN loss, etc).

Most of the time, this is handled smoothly, however, sometimes, when the user has a lock on a record, the operating system still thinks the telnet session is active.

I have a utility to kill processes that are linked together (the telnet session, the perl script they run, the instance of the database they are in), but I am looking for something I can key off automatically (so I can get some sleep).

I have tried to read up on telnetd, etc. but have not found anything relative.

Is there some test I can run routinely to see if a telnet session is still active?

TIA

[RAC_1]

you can do ps -ttty_name for the terminals you see inactive and kill them.

you can put all this stuff in script and run it at regular intervals.

[Arturo Perez del Galleg]

Do you are tried the lsof command?
If you run 'lsof -i tcp:23', how is showed the status of the proccesses? FIN_WAIT2? In this output you have the PID of the proccess.
HTH

[Armin Feller]

Hi,

you can find the lost telnet sessions by following command:

# netstat -a|grep FIN


Using the below script to disconnect the connections

--------------
#!/usr/bin/ksh
#
# "flush_stale_finw2" -- Wolffman 6/2/98
#
# Script to flush stale FIN_WAIT_2 sockets.
# Script execution with the "-f" option results in
# HP machine sending TCP RST along with clean release
# and freeing of associated connection resources.
# (Essentially, returning kernel memory back for reuse.)
#
# Suggestion: invoke via "cron" job during off hours
#
#
#
# Usage: flush_stale_finw2 # To list sockets in FIN_WAIT_2 state
# flush_stale_finw2 -f # To actually force their removal
#
#
if test "$1" = "-f"
then
/usr/bin/ndd -get /dev/tcp tcp_status | grep FIN_WAIT_2 |
awk '{ printf "ndd -set /dev/tcp tcp_discon 0x%s\n", $1 }' > /tmp/finw2
/sbin/chmod 700 /tmp/finw2
/usr/bin/ksh -x /tmp/finw2

/sbin/rm /tmp/finw2
else
/usr/bin/ndd -get /dev/tcp tcp_status | grep FIN_WAIT_2
fi
--------------

Regards ...
Armin

[Chuck J]

Does your script automatically kill hung processes, or do you have to specify a username? If it us automatic why not run it from cron say every 5 mins or something like that.

Chuck J

[Jochen Heuer]

Hi Dan,

if you have access to the knowledge db you can check

http://support.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=KBRCKBRC00002518

for explanations (and a more current version) of this script.

But I don't think this script would help in this situation. Check if there are session in status FIN_WAIT2. Normally if a client just crashes it does not send a fin package so the server would not get in status FIN_WAIT2. I think the session would stay in status ESTABLISHED. Check status with

$ netstat -an

[Armin Feller]

Hi Chack,

please read the answert of Jochen and check his document. I'm not realy sure about the script I posted.

Best regards,
Armin

[Jochen Heuer]

Hi all,

I'm not sure if this works in your case too but I think the auto-logout feature of some shells is more appropriate to end lost (and therefore idle) sessions:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x5be5d211e18ad5118ff10090279cd0f9,00.html

Jochen

[John Meissner]

You can also do a 'last' command

last -R

this will show you the last time people logged in and connections that are still active

[Dan Rosen]

Some clarification:

In my program, I have to enter a username, and it will list for me the terminals that they are connected to and the subprocesses run under that.

There is nothing there (but may be a flag I am not seeing) to show whether or not the terminal is TRULY active.

Right now, I react to user complaint that they cannot access a record, because it says they are already in it. When I research further, they will currently have one telnet session active, but when I look in the system, they will have 2,3, or more active sessions.

I will try some of the responses, but the really fun part of this problem is how intermittent it is!

BTW, I have seen this be worse with users coming in over cable modem using VPN software, in case anyone is wondering

[Mark Greene_1 · Accepted solution]

Have you check the tcp_keepalive kernel parameters?

From the HP on-line docs:

"tcp_keepalive_interval tcp_ip_abort_interval tcp_ip_abort_cinterval

tcp_keepalive_detached_interval

The parameter tcp_keepalive_interval determines the amount of time that TCP waits for an idle connection with no unacknowledged data before sending keepalive packets. The default is 2 hours.
"

see man getsockopt for all the gory details on how this is implemented. Also, if you are running gated, you have to tell it to pay attention to the keepalive signals.

HTH
mark

[Jochen Heuer]

What ARPA transport patch do you have installed?

$ swlist -l product |grep -i arpa

If it is smaller then PHNE_21606 (on 11.0) install a more current version of the ARPA transport patch (reboot required). It could be that out of order fins might bite your system ...

Regards,

Jochen

[Dan Rosen]

Thanks to everyone who is putting their thinking caps on.

I have a better idea, so let me continue to refine:

1. I believe that for some reason, the connection is staying "ESTABLISHED", when I look using the netstat command.

2. Subprocesses (database instance and PERL login script) also remain active. I think that will negate the lowered use of the shell's TMOUT. However, NO ONE uses the shell, so it won't hurt to lower it to 15 minutes.

3. I am looking for the tcp_keepalive_interval, since I believe that may be what I am looking for.

My simple thought is that the daemon telnetd must test the connection SOMEHOW, and that is what I am looking to change. It is almost like sending a "Are You There?" packet, but not quite.

Oh, and just so I clear this up, we are on 10.2.

Thanks!

[Mark Greene_1]

The Keepalive parameters are part of the configurable kernel parameters and should be accessable via sam.

HTH
mark

[Dan Rosen]

Thanks all -

I believe what will help me is a utility called "nettune". It allows me to get to the tcp_keep* settings.

I am going to lower the two hour default, and for a very short confirm time.

Thanks!

[John Palmer]

Hi,

At 10.20, you need to change tcp_keepstart to a much lower value with

nettune -s tcp_keepstart nnnn

On one of our servers, we set this to 300 (5 minutes).

You'll also have to include this in a system startup script in order for it to be set after a reboot.

Regards,
John