From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 1 11:42:24 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 240D116A403; Fri, 1 Dec 2006 11:42:24 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0A2243CA5; Fri, 1 Dec 2006 11:42:09 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from vader ([85.236.96.60]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.0.1) with ESMTP id md50003272420.msg; Fri, 01 Dec 2006 11:41:18 +0000 Message-ID: <011c01c7153d$9c5e1bb0$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: "Robert Watson" , "Bjoern A. Zeeb" References: <00c001c71535$7e7d7670$b3db87d4@multiplay.co.uk><20061201104809.P91892@maildrop.int.zabbadoz.net> <20061201111209.M79653@fledge.watson.org> Date: Fri, 1 Dec 2006 11:41:08 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Processed: multiplay.co.uk, Fri, 01 Dec 2006 11:41:19 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 85.236.96.60 X-Return-Path: killing@multiplay.co.uk X-MDAV-Processed: multiplay.co.uk, Fri, 01 Dec 2006 11:41:19 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: Unable to stop a jail X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2006 11:42:24 -0000 Robert Watson wrote: > Not all cases of straggling jails are leaks -- does netstat -n show > that all the TIME_WAIT TCP connections in the jail have been GC'd? > Because security state may be used in the network stack for TCP > packet transmission/reception, the ucred remains referenced until the > last socket/pcb associated with it are free'd. I've been wondering > if we should add a jail process counter, and hide jails in jls if the > counter is zero (with a -a argument or such to show them). One idea > I've been kicking around is adding a zombie state for jails, in which > some straggling references exist, but (a) there are no processes in > the jail, and (b) no new processes are allowed to enter the jail. > The significance of (b) is that we could vrele() the vnode reference > hung off the jail; there's been at least one report that this vnode > reference causes issues, as the file system it's from can't be > unmounted until the last jail reference evaporates. This appears to not be the case here as there where no references to the address in netstat and no processes remaining. So it does seem there is some sort of leak still remaining there someone where. At one point I did have two "zombie" jails ( of the same jail ) but the second one was due to a socket reference which then just disappeared a minute or so later. > In essence, this would move to having two reference counts on the > prison: a "strong" reference that has to do with having process > members, and a "weak" reference that has to do with ucreds pointing > at the prison. The proposal sounds like a good idea but I'm sure there's an argument that would say thats just hiding the real underlieing issue? Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk.