From owner-freebsd-stable@freebsd.org Mon Oct 31 08:40:57 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5F88C2831F for ; Mon, 31 Oct 2016 08:40:57 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7F129181C for ; Mon, 31 Oct 2016 08:40:56 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id E893C28416; Mon, 31 Oct 2016 09:40:47 +0100 (CET) Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz [86.49.16.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id EA48228411; Mon, 31 Oct 2016 09:40:46 +0100 (CET) Subject: Re: Dying jail To: Peter , freebsd-stable@FreeBSD.ORG References: <581064BB.1030500@rdtc.ru> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <5817038E.3010300@quip.cz> Date: Mon, 31 Oct 2016 09:40:46 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 08:40:57 -0000 Peter wrote on 2016/10/28 14:28: > Eugene Grosbein wrote: >> Hi! >> >> Recently I've upgraded one of my server running 9.3-STABLE with jail >> containing 4.11-STABLE system. >> The host was source-upgraded upto 10.3-STABLE first and next to >> 11.0-STABLE >> and jail configuration migrated to /etc/jail.conf. The jail kept intact. >> >> "service jail start" started the jail successfully >> but "service jail restart" fails due to jail being stuck in "dying" >> state for long time: >> "jls" shows no running jails and "jls -d" shows the dying jail. > > Same issue here. During upgrade to 10 I wrote a proper jail.conf, > and, as this is now a much more transparent handling, I also began to > start+stop my jails individually w/o reboot. > I found the same issue: often jails do not want to fully terminate, but > stay in the "dying" state - sometimes for a minute or so, but sometimes > very long (indefinite). > > It seems this is not related to remaining processes or open files (there > are none) but to network connections/sockets which are still present. > Probably these connections can be displayed with netstat, and probably > netstat -x shows some decreasing counters associated with them - I have > not yet found the opportunity to figure out what they exactly mean, but > anyway it seems like there may be long times involved (hours? forever?), > unless one finds the proper connection and terminates both ends. > > There seems to be no other way to deliberately "kill" such connections > and thereby terminate the jail, so the proposal to let it have a new > number might be the only feasible approach. (I dont like it, I got used > to the numbers of my jails.) I am no sure where but I think it was discussed in jail@ mailing list that keeping the same JID is not recommended. Or recycling freed JID. It was few years ago when I talked about this with BZ. Miroslav Lachman