From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 4 22:03:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3551D8D0; Fri, 4 Apr 2014 22:03:32 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id CEA898EB; Fri, 4 Apr 2014 22:03:31 +0000 (UTC) Received: from study64.tdx.co.uk (study64.tdx.co.uk [62.13.130.231]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s34M3M6q086944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Apr 2014 23:03:23 +0100 (BST) Date: Fri, 04 Apr 2014 23:03:23 +0100 From: Karl Pielorz To: John Baldwin Subject: Re: Stuck CLOSED sockets / sshd / zombies... Message-ID: <9E29C6F47AEE714A4DE171C4@study64.tdx.co.uk> In-Reply-To: <201404041613.09808.jhb@freebsd.org> References: <3FE645E9723756F22EF901AE@Mail-PC.tdx.co.uk> <201404031614.40951.jhb@freebsd.org> <18B08A7E8585B0C4A89A05E6@study64.tdx.co.uk> <201404041613.09808.jhb@freebsd.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 22:03:32 -0000 --On 4 April 2014 16:13:09 -0400 John Baldwin wrote: >> So I'm guessing that's a yes? > > Ugh, ok. Is this easy to reproduce? Hmmm. I cloned the box today, and messed around with ssh on it - and didn't manage to get a single stuck session. The box with the problems has been 'sitting around' for quite a while - with no services on it. I may have just stumbled onto something that I didn't notice before. I've traced all the stuck sshd's back to being created by security scanning software we use to check our hosts. I'm going to run the same scan against the new box and see if that creates some stuck sessions. Obviously, they shouldn't "stick" like this [technically no matter how much they're 'abused']- and, unless the other people involved are running the same security scans against their hosts I can't see it's just being that as a cause - but if the scan does create zombies on the 2nd host - that would at least make it reproducible. I double checked - none of our other boxes (scanned with the same software) show the same issue. I'll do some tests and post back what I find... -Karl