From owner-freebsd-current@FreeBSD.ORG Sat Feb 9 15:53:45 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7599654A; Sat, 9 Feb 2013 15:53:45 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 597F27C; Sat, 9 Feb 2013 15:53:43 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA21433; Sat, 09 Feb 2013 17:53:39 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1U4CkF-00086d-IX; Sat, 09 Feb 2013 17:53:39 +0200 Message-ID: <51167101.4010902@FreeBSD.org> Date: Sat, 09 Feb 2013 17:53:37 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: Fabian Keil Subject: Re: geli(8) breaks after a couple hours of uptime References: <20130207141833.GA15884@acme.spoerlein.net> <20130207153322.5c371beb@fabiankeil.de> <20130207180153.GX35868@acme.spoerlein.net> <20130208095709.6ae61cff@fabiankeil.de> <20130208114825.GY35868@acme.spoerlein.net> <5114F390.4010302@FreeBSD.org> <20130209140733.0b753c60@fabiankeil.de> In-Reply-To: <20130209140733.0b753c60@fabiankeil.de> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Eitan Adler , zont@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2013 15:53:45 -0000 on 09/02/2013 15:07 Fabian Keil said the following: > It also wouldn't hurt to document why a 64K per-process limit with an > unlimited number of processes per user is considered a good default in > the first place. I don't think that maxproc=unlimited is a good default regardless of memorylocked. OTOH, we have kern.maxprocperuid. -- Andriy Gapon