From owner-freebsd-isp Thu Mar 14 07:41:44 1996 Return-Path: owner-isp Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA12845 for isp-outgoing; Thu, 14 Mar 1996 07:41:44 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id HAA12834 for ; Thu, 14 Mar 1996 07:41:41 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id JAA21964; Thu, 14 Mar 1996 09:40:33 -0600 From: Joe Greco Message-Id: <199603141540.JAA21964@brasil.moneng.mei.com> Subject: Re: csh hanging around after disconnect To: boot@mosquito.com (Bruce Bauman) Date: Thu, 14 Mar 1996 09:40:33 -0600 (CST) Cc: freebsd-isp@FreeBSD.org, boot@itchy.mosquito.com In-Reply-To: <199603132126.QAA15850@itchy.mosquito.com> from "Bruce Bauman" at Mar 13, 96 04:26:55 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-isp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Hi. We're an ISP using Livingston portmasters and running 2.1-stable. Our portmasters > are set with an idle timeout of 30 minutes. I have noticed that when users get booted > off by the timeout, their csh process hangs around. Is this a bug? Or am I doing > something wrong on my end. We don't reboot our server very often, so this ends up > being a problem for us. > > Also, we run the poppassd daemon so that users can change their passwords via > Eudora. We have the same problem - if a user disconnects in the middle of > changing their password, the process hangs around forever and ties up a pty. > Does anyone have a fix for this? I've seen Portmasters do all sorts of strangeness with TCP/IP connections, be it SLIP or rlogin... I believe you're running into another variant of one of my old complaints about Portmasters (and the reason I religiously steer people away from these marginal devices)... the Portmasters do goofy things when connections go away. In this case, if memory serves, try putting an Ethernet sniffer (or FreeBSD with tcpdump) on the wire. Connect up, watch the packets. Drop the connection and I would bet a small sum of money that you do not see the Portmaster close down the connection correctly (if at all). MY fix for this particular type of brokenness has always been to enable SO_KEEPALIVE :-) In YOUR case, I would say it's easier to disable the misfeature on the Portmaster and install a Perl script (etc) on your UNIX box to kill idle connections. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968