On Fri, 24 Jul 2009, Kevin King wrote:
> Is there any UDT option that causes a Unidata (7.1.16) session to be dropped
> when the telnet session is inadvertently disconnected? Barring that, when a
> telnet session is inadvertently disconnected is there a reliable way (AIX 5)
> to determine that a session has or does not have a telnet client connected
> to it?
I'll answer this from the perspective of an author of a telnet program.
And by the way, the situation with an SSH connection is essentially the
same.
In general there are two situations:
1. Abrupt Disconnect
If a) the network goes down, b) the user turns off a PC, or c) a user uses
Task Manager to terminate a program, no network activity is received by
the telnet daemon on the server. It will continue thinking all is good
until it tries to send something, or a very long timeout occurs. Sometimes
this is a good thing, because certain kinds of momentary drops in the
network can be auto-repaired, with no loss of session.
Because no termination has been received, the host process continues to
run, waiting for input. You may need to terminate these processes, as they
are essentially phantoms.
2.Orderly Disconnect
If the user shuts down the client session in an orderly way, the client
sends a closure to the host. The telnetd running on the host receives
this, and converts it to a hangup signal, a SIGHUP. It sends this SIGHUP
to the first-level process running on the associated pseudo-TTY (a PTY).
(Terminology and behavior come from the days of modems.)
That is where it gets interesting. Usually the pty is running one or more
shell processes, each with a script, and one or more programs. Consider
this chain of processes:
telnetd -> p1 -> p2 -> p3 -> p4
where p<n> is either a shell process or a program (the capabilities are
the same in what follows, although the syntax is different).
The telnetd detects a disconnect, and sends a SIGHUP to process p1. By
DEFAULT, the signal (SIGHUP) is propogated all the way to p4. Process p4
has a chance to detect that signal, close its files, maybe write log
entries, and terminate cleanly. That termination might cause a termination
in p3, or p3 might separately detect the signal and terminate. This
behavior may be automatic in a particular language environment, or the
application programmer may have a way to get involved in it.
What often happens, though, is that p2, say, "traps" the signal. In a
shell script, the syntax is actually "trap <n>", where "n" is the number
corresponding to SIGHUP (on Linux, "kill -l" tells me that SIGHUP is 1).
If p2 traps the signal and terminates, process p3 and p4 are still running
and are essentially orphaned.
It is also possible for a process to trap and IGNORE a signal. Note also
that some signals are mandatory, and force termination.
Note that the Unix/Linux "kill" command is actually misnamed. It is in
fact a way to send various signals to any process (if you have
permission). Again, "kill -l" lists these signals. So kill can be used to
test the setup. In a scenario like above, I can use "kill -1 <pid>" to
send a SIGHUP to each process in the chain, and find out what happens.
I would do two pieces of research. First, I would find out what support
for signals the runtime language (Pick BASIC, etc.) has, and whether I as
a programmer could tie in to that, and save my files, etc., when a SIGHUP
occurs.
Second, I would send a SIGHUP to p1 above, and see what happens. If all
processes in the chain aren't terminated, I'd look at what intermediate
processes are doing with signals. Usually, I'll find that a shell script
is trapping signal 1, and it shouldn't be.
Hope that helps.
Regards,
....Bob Rasmussen, President, Rasmussen Software, Inc.
personal e-mail: r...@anzio.com
company e-mail: r...@anzio.com
voice: (US) 503-624-0360 (9:00-6:00 Pacific Time)
fax: (US) 503-624-0760
web: http://www.anzio.com
street address: Rasmussen Software, Inc.
10240 SW Nimbus, Suite L9
Portland, OR 97223 USA
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
