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 <[email protected]> wrote: > >> On 11 September 2015 at 13:46, Alfred Perlstein <[email protected]> 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 <[email protected]> wrote: >>>> >>>> >>>>> On Thu, Sep 10, 2015 at 9:53 AM, Ed Maste <[email protected]> wrote: >>>>> >>>>>> On 10 September 2015 at 04:05, Adrian Chadd <[email protected]> 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 > _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "[email protected]"
