I've got an annoying problem with a simple solution but a more
eloquent solution would be better. I have users connecting to my
systems with telnet clients that will drop the connection leaving
applications still running. The client pieces are located on about
8,000 individual disks which I don't own so fixing that part of the
puzzle is a tad daunting at the moment. The simple solution is to
locate the sessions, connect to the DB server and cleanly terminate
their database connections then kill the processes. A more elegant
and acceptable solution to my management would be to take over the
session and terminate it from within. Has anyone here had any
experience with hijacking an abandoned telnet sessions either from Perl
or C?
--
-----------------------------------------------------------------------
|Chuck Mattern | "People often find it easier to be a result |
|camattern@acm.org | of the past than a cause of the future." |
-----------------------------------------------------------------------

On 08 Sep 2003 00:11:32 -0400, Chuck Mattern <camattern@acm.org>
wrote:

>A more elegant
>and acceptable solution to my management would be to take over the
>session and terminate it from within.

More elegant, but less secure. Further, hijacking a session which has
terminated abnormally may actually cause more damage than using the
method you already have!

I'm curious as to why management thinks this is "more acceptable" than
doing it the way you are now?

Mark Landin <mark.landin@tdwilliamson.com> writes:

> More elegant, but less secure. Further, hijacking a session which has
> terminated abnormally may actually cause more damage than using the
> method you already have!
>
> I'm curious as to why management thinks this is "more acceptable" than
> doing it the way you are now?

While I feel happy with my solution there is a belief that by getting
inside the session and sending a stream of strings representing the F3
key we can get the application to exit normally (F3 being our default
exit signal) but of course there is the element of what term type the
client was using (typically a vt220 but this too is a potential issue).
The original idea (not mine) was to enhance the client to time out,
send a series of F3's then disconnect, The problem is that there is no
guarantee that an F3 will actually effect an exit as some of the
screens are expecting an F12 to cancel and in any case disconnecting
without knowing if the session really terminated will doubtless lead
to more abandoned sessions and possibly problems with the database is
the application is in a critical section (my method checks to see if
the Informix sessions are in transaction or rollback, attempts to
wait those conditions out if they are found and opens a trouble
ticket without killing the processes if it is unable to safely
disconnect. _IF_ I could hijack the session I would have the options
of sending down a looping string of F3s and F12s for each of the term
types we use for a predetermined number of iterations, and if the
session were still active then it could be terminated by my original
method. To be honest I feel my original method is quite adequate but
there is that due diligence thing so I'm asking here. If nothing else
at least I'll be able to say that I checked with my peers and there
was a consensus that my approach is valid and somewhat safer.

Thanks for any and all feedback,
Chuck

--
-----------------------------------------------------------------------
|Chuck Mattern | "People often find it easier to be a result |
|camattern@acm.org | of the past than a cause of the future." |
-----------------------------------------------------------------------

Chuck Mattern wrote:
> I've got an annoying problem with a simple solution but a more
> eloquent solution would be better. I have users connecting to my
> systems with telnet clients that will drop the connection leaving
> applications still running. The client pieces are located on about
> 8,000 individual disks which I don't own so fixing that part of the
> puzzle is a tad daunting at the moment. The simple solution is to
> locate the sessions, connect to the DB server and cleanly terminate
> their database connections then kill the processes. A more elegant
> and acceptable solution to my management would be to take over the
> session and terminate it from within. Has anyone here had any
> experience with hijacking an abandoned telnet sessions either from Perl
> or C?

Sorry for the delay in this, the news server I access has been down
for days...

We wrote/sell a program call PEEK. This software let you see what
someone is doing AND lets you type keystrokes on their behalf.
You can control who can look at who, you can use an audit trail to
log what is going on. And you can script it, so you could send the
keystrokes you wish.

But it is not for GUI sessions. It'll work for any telnet/xterm
text window, serial, etc., just not a full GUI app. Is this helpful?
You can get details by sending a message to peek@computron.com or
visit www.computron.com

Thanks!

Randy Styka, randy@computron.com