Idle Users
Bill Vermillion
fp at wjv.com
Thu Jun 17 17:15:18 PDT 2004
On Thu, Jun 17, 2004 at 05:03:36PM -0400, Fairlight thus spoke:
> Only Vicky Prigg would say something like:
> > How can we log off idle users? We have an SCO Unix system
> > accessed by DejaWin. We are having problems with records
> > being locked and I assume that the users are clicking 'x'
> > instead of properly logging out of filePro, thus leaving open
> > processes. I?m guessing that idleout doesn?t work in this
> > case. Thanks for your help.
> The problem with this theory is that if the session is terminated
> with SIGHUP, all child processes should die along with the shell
> process--including any filePro processes.
> Do you actually see stranded filePro processes in the process
> table, or is this strictly an assumption on your part?
I never saw an answer to this, but in the past it was common
in SCO to see users logged in that were no longer connected.
I've searched for the archives I have here and was unsuccessful
in a google search, but from my recollection the timeout on
a TCP/IP connection on older SCO implementations was obsccenely
long - memory says about 2 hours.
I also recall at one time there was a patch/configuration for it to
turn it to more reasonable timings. I don't know why the original
was so long but it could easily have been one of those typical
errors caused by setting a number and assuming the units were
different than they acutally were - eg assuming milliseconds when
the timing was seconds. Or like one of the Mars probes using feet
instead of meters.
I remember many people having problems with it, and I don't know if
was fixed in the current SCO - and the OP did not mention the
version of SCO Unix.
I had an outdate link that went nowhere, but furhter searching gave
me a TA that I had saved.
At the risk of perhaps not helping at all let me add that TA
to this message. The OP needs to look at this and see if the users
still appear to be logged in. Note in this the differentiation
between keepalive and idleout.
========================================
TA Home
Configure telnetd to close connection when client connection no longer exists.
_________________________________________________________________
Keywords
clients closed closes configured connections connectivity
crashes diagnostics disconnected enterprise established exists
failed failing faststart finger flags frequency idles idleouts
inconfig incorrectly inetd inittab internet intervals intranets
ips keepalives keepidle keepintvl listens logins longer nkeep
noluid nowait openserver options parameters probes ps rebooting
reboots releases resets richard rlogind sco sco-236-990 ttloop
peer died 5.0.5 5.0.6 505 506
Release
SCO OpenServer Enterprise System Release 5.0.5, 5.0.6
SCO OpenServer Enterprise System Release 5.0.0, 5.0.2, 5.0.4
SCO OpenServer Desktop System Release 5.0.0, 5.0.2, 5.0.4
SCO OpenServer Host System Release 5.0.0, 5.0.2, 5.0.4
SCO OpenServer Internet FastStart Release 5.0.4
SCO Internet FastStart Release 1.0.0, 1.1.0
Problem
Commands such as who(C), finger(C), and ps(C) may show
established telnet sessions when the client end of the TCP
connection no longer exists, for example, when the client
computer crashes, is powered off or reset without first closing
the telnet session. Established sessions may also be shown when
network connectivity to the client has failed. There may also
be errors in /usr/adm/syslog:
telnetd: ttloop peer died
Cause
The telnet server daemon, telnetd(ADMN), arranges to use TCP
transport-level keepalive probes to distinguish an inactive
client from a TCP connection for which the remote end of the
connection no longer exists. When TCP finds a connection has
been inactive for a specified period of time, it sends a
keepalive probe to the client, and listens for a response. If
there is no response to the probe, additional probes are sent
at a specified frequency. If there is no response from the
client after a specified number of probes have been sent, it is
assumed that the connection has been lost, and the telnet
session is closed. If the client responds to a probe, the
session is kept alive. This sequence of events is repeated if
the session remains or again becomes idle. The timing for the
sequence of events is determined by the three parameters just
mentioned: idle interval, probe frequency, and number of
probes. These values may be specified by telnetd, or left at
the system-wide defaults.
When the who and ps commands both show a telnet login as
active, it is likely that they are correctly reporting a
session that hasn't been closed by the client, and for which
the sequence of events leading to automatic closing of the
connection by the server, hasn't completed. That will be the
case for an ordinary established connection over a properly
functioning network. That will also be the case when keepalive
probing hasn't yet completed for a client that has failed to
disconnect properly, or with which connectivity has been lost.
In the most insidious case, the client's TCP may not respond
correctly to keepalive probes after failing to disconnect
properly, and then rebooting. Rather than sending a reset
response, the client sends an acknowledgement, causing the
connection to be kept alive when it should have been closed.
This article addresses the above cases. In particular, the
"Solution" section of this article addresses how telnetd's
keepalive parameters can be modified to minimize problems due
to telnet clients that fail to disconnect properly.
When who shows a telnet user logged in, while ps shows that the
session has in fact been closed, it is possible that /etc/utmp
and related files have stale entries. Output from who and
related commands is based on these files. The stale entries may
be due to corruption in files that are read by utilities that
update utmp, or to faulty third-party software. These cases are
addressed in other technical articles in the SCO Support
Library, listed at the end of this article. Note that it is
possible to have both types of problem appear on the same
system.
Solution
Use the following diagnostic to distinguish the two problem
types just mentioned ("#" indicates the root command line
prompt):
# kill -0 `who -u | awk '{print $7;}'`
Any output indicates a stale /etc/utmp entry associated with
that process id. Consult other technical articles in this
database, listed at the end of this article, for guidance in
dealing with stale utmp entries. This article applies in cases
for which the diagnostic produces no output.
The sending of keepalive probes can be configured to reduce the
problem of telnet sessions that haven't been disconnected
properly. Some experimentation may be necessary to find the
configuration that works best with the clients on a given
network. The parameters that may be configured are described in
the Keepalives section of the telnetd(ADMN) man page:
Keepalives ++++++++++
Transport-level keepalive messages are enabled unless the -n
option is present. The use of keepalive messages allows
sessions to be timed out if the client crashes or becomes
unreachable.
If keepalives are being used, several parameters may be
controlled using the following options:
-k n The argument n specifies the time (in seconds) that a connection
must be idle before the first keepalive probe will be sent.
-K n The argument n specifies the interval (in seconds) between
keepalive probes if no response is received.
-N n The argument n specifies the number of unanswered keepalive probes
that will be sent prior to dropping the connection.
The default keepalive values corresponding to these options are
controlled by the parameters tcp_keepidle (7200 seconds),
tcp_keepintvl (75 seconds), and tcp_nkeep (8). These can be
tuned on a system-wide basis using inconfig (ADMN). These
options exist solely to provide finer control of keepalives on
per application basis.
Note
The last paragraph of the man page excerpt above refers to
system- wide defaults. The keepalive options provided by the
telnet server daemon allow these system-wide keepalive
parameters to be overridden for telnet connections, without
affecting keepalive behavior of other applications.
The minimum value of 10 for -k is not documented in the man
page. Values less than 10 for the -k flag will be ignored, and
the default value will be used.
Because telnetd(ADMN) is started by inetd(ADMN), the keepalive
flags need to be appended to the telnet line in
/etc/inetd.conf.
As an example, the line:
telnet stream tcp nowait NOLUID /etc/telnetd telnetd
would be edited with vi(C) to read:
telnet stream tcp nowait NOLUID /etc/telnetd telnetd -k 30 -K 1 -N 6
Execute the following command to apply the new configuration:
# kill -1 `cat /etc/inetd.pid`
The values given in this example are chosen so that a session
will be idle thirty seconds (-k 30) before the first probe is
sent, will probe every second (-K 1) until a response is
received, or will close the session if no response is received
during five seconds of probing (-N 6 and -K 1).
The values in this example might apply for an intranet with
fast and reliable connectivity, and a problem client that
answers keepalive probes incorrectly. If the client reboots
quickly, these aggressive values may be of no avail. A shorter
idle time may be configured, down to the minimum value of 10
for -k, but this will further burden the network with keepalive
probe traffic, possibly leading to network performance
problems.
A second example illustrates possible values for a slower and
less reliable Internet connection, with a client that correctly
responds to keepalive probes:
telnet stream tcp nowait NOLUID /etc/telnetd telnetd -k 60 -K 30 -N 5
In this case, a session will be idle one minute (-k 60) before
the first probe is sent, will probe every thirty seconds (-K
30) until a response is received, or will close the session if
no response is received during two minutes of probing (-N 5 and
-K 30).
The number of seconds of probing is given by:
K * ( N -1 )
The number of seconds from the last activity to the last probe
is given by:
k + ( K * ( N -1 ))
This is over two hours using the system defaults, and 35
seconds and three minutes, respectively, in the examples.
A third example illustrates an alternative approach: putting
multiple telnet services on different ports, with different
sets of keepalive parameters, and configuring only misbehaved
clients to come in through a fast-timeout port.
A fast-timeout telnet port is set up in /etc/services on a port
not already in use (823 in this example):
telnet2 823/tcp # fast-timeout telnet port
A corresponding entry is made in /etc/inetd.conf, with
keepalive values appropriate for the clients that will be
configured to use the fast-timeout telnet port:
telnet stream tcp nowait NOLUID /etc/telnetd telnetd
telnet2 stream tcp nowait NOLUID /etc/telnetd telnetd -k 30 -K 1 -N 6
Apply the server configuration as in the other examples, and
configure the misbehaved telnet clients to use port 823 instead
of 23. It is important to note that some telnet clients cannot
be configured to connect to ports other than the default port
23. The approach suggested in this third example cannot be used
with such clients.
The examples are intended to be illustrative; the values chosen
will depend on the specific situation. Some experimentation may
be required to determine the best values.
Note
The function of keepalive probes is sometimes confused with
that of idleout(ADM). Keepalive probes serve to distinguish
inactive connections from failed connections, for the purpose
of automatically closing failed connections, whereas idleout
serves to close idle logins, regardless of whether or not the
connection has failed. Keepalives will not cause a telnet
session to be closed just because a user isn't typing.
Note
The rlogin server daemon, rlogind(ADMN), also allows
configuration of keepalive parameters. See Technical Article
107693, "Configure rlogind to close connection when client
connection no longer exists."
See Also
who(C); whodo(C); finger(C); ps(C); netstat(TC); telnetd(ADMN);
inetd(ADMN); setsockopt(SSC); awk(C); kill(C); cat(C); sh(C)
rlogind(ADMN)
"TCP/IP Illustrated", Vol 1, by Richard Stevens, ISBN
0-201-63346-9, for a discussion of keepalives in detail beyond
the scope of this article.
For cases involving stale /etc/utmp entries, the following
articles apply:
Technical Article 105610, "I want to clear my system of users
who are not logged in."
Technical Article 104857, "Log in and get "no utmp entry. You
must log in from lowest level -sh."
Technical Article 104588, "Rebuild ttys file from inittab
including pseudo ttys after crash."
Technical Article 105397, ""Who" or "whodo" command sometimes
returns info for users no longer logged in."
_________________________________________________________________
TA107691 created on 02 July 1997 , last updated on 14 January 2002
SSL #: 640474 IT #: tcpip474
_________________________________________________________________
Copyright © 1996-2000 The Santa Cruz Operation, Inc.
All Rights Reserved.
========================================
--
Bill Vermillion - bv @ wjv . com
More information about the Filepro-list
mailing list