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