From owner-freebsd-bugs  Wed Feb  5 16:20:15 1997
Return-Path: <owner-bugs>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id QAA27349
          for bugs-outgoing; Wed, 5 Feb 1997 16:20:15 -0800 (PST)
Received: (from gnats@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id QAA27321;
          Wed, 5 Feb 1997 16:20:07 -0800 (PST)
Resent-Date: Wed, 5 Feb 1997 16:20:07 -0800 (PST)
Resent-Message-Id: <199702060020.QAA27321@freefall.freebsd.org>
Resent-From: gnats (GNATS Management)
Resent-To: freebsd-bugs
Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, jmaslak@blackfire.com
Received: from blackfire.com (hill153.uwyo.edu [129.72.150.153])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA26800
          for <FreeBSD-gnats-submit@freebsd.org>; Wed, 5 Feb 1997 16:15:30 -0800 (PST)
Received: (qmail 6257 invoked by uid 500); 6 Feb 1997 00:15:45 -0000
Message-Id: <19970206001545.6256.qmail@blackfire.com>
Date: 6 Feb 1997 00:15:45 -0000
From: jmaslak@blackfire.com
Reply-To: jmaslak@blackfire.com
To: FreeBSD-gnats-submit@freebsd.org
X-Send-Pr-Version: 3.2
Subject: bin/2672: Problem with telnetd
Sender: owner-bugs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


>Number:         2672
>Category:       bin
>Synopsis:       Problem with telnetd
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Feb  5 16:20:04 PST 1997
>Last-Modified:
>Originator:     Joel Maslak
>Organization:
Not Likely!   
>Release:        FreeBSD 3.0-CURRENT i386
>Environment:

	FreeBSD Current 3.0, December 1996 update.  TCP Host, several active
	users (10 users).  Incomming telnets from distant TCP/IP hosts, using
	semi-reliable networks.

>Description:

	Sometimes users who disconnect leave a telnetd behind.  This is caused,
	apparently, by users disconnecting incorrectly (shutting off remote
	workstation, loss of network connectivity, etc).  The shell process which
	is eventually spawned durring the incomming telnet eventially dies, but the
	telnetd does not.  Thus, "w" and "who" reveal no logged in users on a TTY,
	yet that TTY will not be assigned to incomming connections (telnetd still
	has control of one side of it).

	The terminal in this case had not been assigned for ten days (until I
	noticed that it was "stuck").  Obviously this isn't a major problem
	for my system, with only ten users, but it would be for a large, heavily
	used machine.  Obviously even TCP should time out in 10 days!

>How-To-Repeat:

	Unknown, see above.

>Fix:
	
	Workarround: Kill old telnetd's that aren't being used.  Be careful.
	A sighup seems to work fine.
	(look at ps -axu | grep telnetd, and select one with a start time that
	does not appear for any logged in users as the login time)
>Audit-Trail:
>Unformatted: