From owner-svn-src-all@freebsd.org Fri Sep 11 22:51:04 2015 Return-Path: Delivered-To: svn-src-all@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 AE152A01195; Fri, 11 Sep 2015 22:51:04 +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 96FF3192A; Fri, 11 Sep 2015 22:51:04 +0000 (UTC) (envelope-from bright@mu.org) Received: from [10.2.98.58] (173-228-14-211.dedicated.static.sonic.net [173.228.14.211]) by elvis.mu.org (Postfix) with ESMTPSA id 4C8F8345A8FA; Fri, 11 Sep 2015 15:51:04 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: svn commit: r287606 - head/sys/kern From: Alfred Perlstein X-Mailer: iPhone Mail (12H321) In-Reply-To: Date: Fri, 11 Sep 2015 15:51:03 -0700 Cc: Warner Losh , Ed Maste , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <201509100405.t8A45xrJ070199@repo.freebsd.org> <55F33D96.8060300@mu.org> To: Adrian Chadd X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 22:51:04 -0000 The idea is sane defaults. Surely 256k makes sense for a machine with that m= uch memory.=20 Sent from my iPhone > On Sep 11, 2015, at 2:02 PM, Adrian Chadd wrote: >=20 >> On 11 September 2015 at 13:46, Alfred Perlstein wrote: >> 64k hard is too low a number for large memory machines. >=20 > Root can always bump it up all the way to kern.maxfilesperproc. >=20 > I'm also a big fan of having the description of config of service > stuff be in /etc/rc.conf, rather than splattered around the place. So > I also like the idea of _rlimit_openfiles=3D"xxxx" so it can be > clearly overridden for services that require it. >=20 > I'm open to other suggestions! >=20 >=20 >=20 > -adrian >=20 >> -Alfred >>=20 >>=20 >>> On 9/10/15 9:18 AM, Adrian Chadd wrote: >>>=20 >>>> On 10 September 2015 at 09:04, Warner Losh wrote: >>>>=20 >>>>=20 >>>>> On Thu, Sep 10, 2015 at 9:53 AM, Ed Maste wrote: >>>>>=20 >>>>>> On 10 September 2015 at 04:05, Adrian Chadd wrot= e: >>>>>>=20 >>>>>> Author: adrian >>>>>> Date: Thu Sep 10 04:05:58 2015 >>>>>> New Revision: 287606 >>>>>> URL: https://svnweb.freebsd.org/changeset/base/287606 >>>>>>=20 >>>>>> Log: >>>>>> Also make kern.maxfilesperproc a boot time tunable. >>>>>> ... >>>>>> TODO: >>>>>=20 >>>>> Also "we" should >>>>> * Submit patches upstream or to the ports tree to use closefrom >>>>=20 >>>>=20 >>>> 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. >>>=20 >>> I'm looking at how to do this in a somewhat sensible fashion. Right >>> now we just have openfiles=3Dunlimited; 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. >>>=20 >>> I think the more sensible default would be: >>>=20 >>> * set /etc/login.conf to some much lower values - say, 4k soft, 64k har= d; >>> * 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. >>>=20 >>> 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. >>>=20 >>> Thoughts? >>>=20 >>>=20 >>> -adrian >=20