Timeout ( verb ) a TCP connection

[Tom Dawson]

Hi,

We have an application running on 11.11 that is accessed via telnet from RF devices. The end users rarely logoff the RF devices when they end their shift, go to lunch, etc.

This leaves a lot of telnet connections open on the server. I would like to be able to proactively "timeout" these connections after a given interval of time ( maybe 5 minutes).

I've been reading through these forums about tcp_keepalive_interval, but it appears that as long as the RF devices respond with ACK to the keepalive packets, our connection stays open. And the RF devices are always powered-up, so I suspect they always respond.

I've looked at lsof and monitoring TCP entries that are in an idle state. But I could end up killing processes I don't want to kill.

Any suggestions?

TIA,
Tom

[Mark Grant]

Couldn't you just set the TMOUT variable. Set this to a number of seconds and it will log them out.

[Tom Dawson]

Mark,

Thanks. But the one bit of ( naive ) security we have on this app is that the RF users are forced into the application upon logging into the shell, then the shell is terminated when they leave the app. So they are never really executing shell commands.

We tried this back in ( circa ) 1998 and it didn't work. I forget if it was because they never timed out, or they always timed out. But we shelved the "shell" option then.

If this doesn't make sense, I could try it again. But I thought we'd had that option covered.

Thanks again,
Tom

[Steven E. Protter · Accepted solution]

It the user is in the application, the TMOUT variable will not help.

Most applications have a queue and timeout users or change their state to inactive.

Example.

Software AG adabase times out users on our system after 15 minutes.

Those users status in the adaopr utility is changed to #### The Process ID is included in the utility.

So a run the adaopr utility to a file, use awk to get the Process id of anyone with #### status. Then the script issues a kill on the PID.

This is a concept. If your application has a tool for indicating inactive users, you can use it much in the same way I use the adaopr utility.

SEP

[A. Clay Stephenson]

Here is an outline of a method I used long before shell's had a TMOUT variable and it will work for more than shells.

Do a ps -e | awk '{print $1,$2,$4'} | while read PID TTY PROC
do
if [[ "${TTY}" != "?" ]]
then
# now I would check to see is ${PROC} is not in a list of "protected" process names defined in a file on in your script
# next determine the last modification time of ${TTY}; if it is older than some arbitrary value then kill the process using kill -15, kill -1, kill -2, kill -3, kill -11 in that order --- send a kill -0 ${PID} and look at the exit status; if it's zero the process still lives. DO NOT SEND a kill -9.

fi
done

If I were doing this, I would use Perl because checking the last modification time is very easy using stat().

[Tom Dawson]

Steven, Clay,

Thanks for both your responses.

Clay,

Don't take this wrong, but that's exactly what I was trying to avoid! But since you're recommending the scripting solution, that tells me I was on the right track. I was hoping there might be a more elegant solution.

I'll probably wait a couple days to put the bunnies up. I'll see if anyone else has any good suggestions.

Thanks again,
Tom

[rick jones]

I am afraid that your analysis of the tcp_keepalive_interval is correct - it is not there to terminate "idle" TCP connections, but to detect when the remote TCP has gone away.

Also, you are quite correct that killing TCP connections out-of-band is not a good way to go either.

There is no way in TCP to have a connection terminated after a period of idleness.

The "best" thing to have here is an application that employs an idle timeout of its own. Barring that, the scripting stuff already mentioned may be your only choice, apart from a "user re-education camp..."

...drifting slightly...on the topic of a re-education camp... when I was in high-school, our Physics teacher wanted to make especially sure that we understood the distinction between mass and weight. So, he had all of use get up out of our chairs, start jumping up and down, and shout "MASS IS NOT WEIGHT! MASS IS NOT WEIGHT" at the top of our lungs. If you care to complete the picture, this was a group of about 15 prep-school boys in jacket and tie.

Suffice it to say, we remember the difference between mass and weight...along with the first 18 lines of Catebury Tales, but that is another story... :)

Anyhow, if you can get mgmt buy-in, you might try that with your RF users. A chant of say "I WILL LOG OUT! I WILL LOG OUT!"

[Bill Hassell]

Keeping RF users out of a shell is a great idea. You may even want to replace the shell in passwd with the application program so they don't even waste the parent shell to get started. However, there is an easy way to fix this. Your application needs a rewrite. It knows when there are tasks pending and when there it is just idle. You'll need to teach your programmers about how to perform I/O timeouts, perhaps even teach them on how to kill themselves (the programs not the programmers) if expected responses take too long.

[Tom Dawson]

Rick, Bill,

Thanks so much for your comments.

Along the lines of "Mass is NOT weight", I need to teach my DBA that just becasue Oracle says use the default port of nnnn, does not mean it has been registered with IANA.

And yes, this app needs a rewrite. It was obsolete when it went in ( 1998 ), but I fear I will have to live with it for at least another 5 years. That might be my only leverage in getting them to at least rewrite the RF part.

Thanks again,
Tom