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>
"Note that rlogind runs only when the remote request is made and<br>
only for the duration of the remote login"<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 "in kernel rlogin". <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 "Unix Network Programming". This book states: <br>
<< 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 ... >> 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 "Man with Big Stick Who Will Hit You If You Don't Log Out Correctly 101"

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 "telnet" instead of "rlogin". The only problem with that may be that a colleague recalls the application we use won't work correctly over "telnet". something to do with key mappings...<br>
<br>
Guess it's these little things in life that help to keep us in a job