From owner-svn-src-head@freebsd.org Fri Sep 11 20:42:27 2015 Return-Path: Delivered-To: svn-src-head@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 01757A0186E; Fri, 11 Sep 2015 20:42:27 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id E2B0E1DCF; Fri, 11 Sep 2015 20:42:26 +0000 (UTC) (envelope-from bright@mu.org) Received: from Alfreds-MacBook-Pro.local (173-228-14-211.dedicated.static.sonic.net [173.228.14.211]) by elvis.mu.org (Postfix) with ESMTPSA id 4F4D3345A8F5; Fri, 11 Sep 2015 13:42:26 -0700 (PDT) Subject: Re: svn commit: r287606 - head/sys/kern To: Adrian Chadd , Warner Losh References: <201509100405.t8A45xrJ070199@repo.freebsd.org> Cc: Ed Maste , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" From: Alfred Perlstein Message-ID: <55F33D96.8060300@mu.org> Date: Fri, 11 Sep 2015 13:46:14 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 20:42:27 -0000 64k hard is too low a number for large memory machines. -Alfred On 9/10/15 9:18 AM, Adrian Chadd wrote: > On 10 September 2015 at 09:04, Warner Losh wrote: >> >> On Thu, Sep 10, 2015 at 9:53 AM, Ed Maste wrote: >>> On 10 September 2015 at 04:05, Adrian Chadd wrote: >>>> Author: adrian >>>> Date: Thu Sep 10 04:05:58 2015 >>>> New Revision: 287606 >>>> URL: https://svnweb.freebsd.org/changeset/base/287606 >>>> >>>> Log: >>>> Also make kern.maxfilesperproc a boot time tunable. >>>> ... >>>> TODO: >>> Also "we" should >>> * Submit patches upstream or to the ports tree to use closefrom >> >> I thought the consensus was that we'd fix things to have fewer FDs >> by default, but instead allow individual processes to raise it via the >> usual methods. > I'm looking at how to do this in a somewhat sensible fashion. Right > now we just have openfiles=unlimited; in /etc/login.conf which seems a > little odd. I don't know yet if that affects the default set that > services started via /etc/rc get - init gets the whole default > maxfilesperproc and stuff seems to inherit from that unless told > otherwise. > > I think the more sensible default would be: > > * set /etc/login.conf to some much lower values - say, 4k soft, 64k hard; > * root can always override its settings up to kern.maxfilesperproc; > * modify /etc/rc to set some default rlimits as appropriate; > * introduce configuration options ({daemon_rlimit_XXX}?) in > /etc/rc.conf that lets someone override what the default rlimits > should be for a given process,, as (and I'm not making this up) if you > run 'service XXX restart' from a root login you get the rlimits from > the shell, which may differ from the system startup. > > That way we can setup various services to have higher openfile limits > via /etc/rc.conf entries for those services rather than having to hack > each startup script. It also means that no matter what is running > 'service XXX YYY' as root, you'll get the 'correct'(er) rlimits. > > Thoughts? > > > -adrian >