Date: 6 Feb 1997 00:15:45 -0000 From: jmaslak@blackfire.com To: FreeBSD-gnats-submit@freebsd.org Subject: bin/2672: Problem with telnetd Message-ID: <19970206001545.6256.qmail@blackfire.com> Resent-Message-ID: <199702060020.QAA27321@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970206001545.6256.qmail>