svn commit: r287606 - head/sys/kern

[Alfred Perlstein]

The idea is sane defaults. Surely 256k makes sense for a machine with that much memory. 

Sent from my iPhone

> On Sep 11, 2015, at 2:02 PM, Adrian Chadd <adrian at freebsd.org> wrote:
> 
>> On 11 September 2015 at 13:46, Alfred Perlstein <bright at mu.org> wrote:
>> 64k hard is too low a number for large memory machines.
> 
> Root can always bump it up all the way to kern.maxfilesperproc.
> 
> 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 <service>_rlimit_openfiles="xxxx" so it can be
> clearly overridden for services that require it.
> 
> I'm open to other suggestions!
> 
> 
> 
> -adrian
> 
>> -Alfred
>> 
>> 
>>> On 9/10/15 9:18 AM, Adrian Chadd wrote:
>>> 
>>>> On 10 September 2015 at 09:04, Warner Losh <imp at bsdimp.com> wrote:
>>>> 
>>>> 
>>>>> On Thu, Sep 10, 2015 at 9:53 AM, Ed Maste <emaste at freebsd.org> wrote:
>>>>> 
>>>>>> On 10 September 2015 at 04:05, Adrian Chadd <adrian at freebsd.org> 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
>