Unixware 7.0 doesn't hang up terminated telnet sessions

[AndyBo]

We've recently upgrade from UW2.1.3 to UW7.0.1. The terminal package we use to connect in to the system lets users hit the Windoze 'x' control to terminate their connection. The user's login sessions aren't being terminated when this happens. Under UW2.1.3, the login session was terminated by the OS, and we didn't have any problems.<br>
<br>
The problems we do get are that the users' application is a bit brain dead, and it ends up in an endless loop taking more and more resources until the system starts to grind to a halt.<br>
<br>
We're trying to educate the user's on logging out correctly (although the big hammer we've been using for this is getting a bit worn ;^); we're stuck with the application; and we're stuck with the terminal emulation package.<br>
<br>
Anyone got any suggestions? Is there, maybe, an option hidden away somewhere - a 'reset dead telnet connections' type thing?<br>
<br>
Here's hoping...

 

[AndyBo]

When a user terminates their session, the process are detached from any TTY and show as &quot;?&quot; in a 'ps -fu username' listing. So, from this we can tell that the session has been detached and can kill the processes...<br>
<br>
The problem with this is, the user may have started to run, for example, a report in the background, and we may be killing off a valid process. This means we can't script anything to automatically kill off these processes...

 

[Guest_imported]

Hm. Original posting Dec 9th. I may be beating a dead horse, but...<br>
<br>
Is it possible that your new o/s version is trapping the sighup, perhaps by a

 

[AndyBo]

I think I see what you're getting at, even though your post has been truncated Here's a copy of an entry from our support vendor's knowledge base that relates to the problem we are having:<br>
<br>
Summary<br>
UnixWare 7 processes do not die on close of VT320+ rlogin<br>
<br>
SYMPTOMS<br>
The problem I am experiencing is that my application expects to receive a SIGHUP when the terminal is disconnected. With 'telnet' connections into UnixWare I do. With 'rlogin' connections I don't. Instead, I get a ECONNRESET error to my read(), which the application chooses to ignore. <br>
Is UnixWare wrong in not supplying the SIGHUP, or must the application be changed ?<br>
<br>
PROBLEM<br>
The reason for this difference is that telnet connections receive their SIGHUP from in.telnetd, whereas on UnixWare 2.1.2 and UnixWare 7 systems, in.rlogind exits immediately after spawning the child process to run the user shell. I have looked that the code and there appears to be a difference in the code for in.rlogind between UnixWare 2.01 and later releases. Specifically :- <br>
UW 2.01 in.rlogind<br>
------------------<br>
pid = fork();<br>
if (pid == 0) {<br>
----- snip ----- child process code, becomes the shell<br>
}<br>
close(t);<br>
ioctl(...)<br>
signal(...)<br>
setpgrp();<br>
protocol(f,p);<br>
signal(..)<br>
cleanup();<br>
}<br>
<br>
<br>
UW 2.1.1 in.rlogind<br>
------------------<br>
pid = fork();<br>
if (pid == 0) {<br>
----- snip ----- child process code, becomes the shell<br>
}<br>
exit(0);<br>
}<br>
<br>
As you can see this means that on later versions of UW, in.rlogind exits<br>
immediately after spawning its child, which means that the user shell will<br>
have a PPID = 1. Note that this is also in contradiction to the dynatext<br>
Network Administration document, which states for rlogind:<br>
<br>
&quot;Note that rlogind runs only when the remote request is made and<br>
only for the duration of the remote login&quot;<br>
<br>
If I log into a DRS/NX system, then in.rlogind runs while I'm rlogin'ed in, and<br>
a truss shows SIGHUP being received.<br>
<br>
EXPLANATION<br>
I know of no documentation that shows the action taken by UnixWare to be incorrect. SCO have no plans to amend the rlogin code. <br>
Normally, you need to test ECONNRESET not SIGHUP. The source code change was introduced when Novell owned UnixWare (UW2.02) for rlogin performance reasons, i.e as part of &quot;in kernel rlogin&quot;. <br>
There is no RFC nor guideline to define the way to manage the errors or signals and so it is implemented to give the best reliabily and performance . <br>
One place to look is the good book from W. Richard Stevens &quot;Unix Network Programming&quot;. This book states: <br>
&lt;&lt; Recall with a TCP socket that the receipt of a FIN causes read to return 0<br>
and the receipt of an RST causes read to return -1, with errno set to ECONNRESET ... &gt;&gt; p774 <br>
The application program needs to take appropriate action on receipt of the ECONNRESET errno indicating a failure.<br>
<br>
~~~~~~~~~~~~~~~<br>
<br>
So, in other words, what looks like a relatively small performance enhancement is causing the problem we are getting. And we're stuck with it <br>
<br>
Fortunately, out user education program (known as &quot;Man with Big Stick Who Will Hit You If You Don't Log Out Correctly 101&quot seems to be working, and it's not as big a problem as it was. In the long term, we're going to be changing the terminal emulation package to use &quot;telnet&quot; instead of &quot;rlogin&quot;. The only problem with that may be that a colleague recalls the application we use won't work correctly over &quot;telnet&quot;. something to do with key mappings...<br>
<br>
Guess it's these little things in life that help to keep us in a job