svn commit: r287606 - head/sys/kern

[Allan Jude]

On 2015-09-10 13:53, John-Mark Gurney wrote:
> Adrian Chadd wrote this message on Thu, Sep 10, 2015 at 09:18 -0700:
>> 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;
> 
> We should probably just use the daemon class from login.conf... Do we
> have a program that will set the current limits to a specified class?
> 

/sbin/init applies the 'daemon' class to /etc/rc when it starts it

And so all rc.d scripts inherit it.

the issue is that it does not apply to services started manually, or via
the service(8) command.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=161401 (reported in
2011, working on getting this in this weekend)

>> * 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.
> 
> Why not daemon_login_class w/ the above?

This is what I was thinking, as it also jives with my work to convert
login.conf to UCL and improve it overall. This would allow services to
install their own login class as part of the package, into
/usr/local/etc/login.conf.d/pkgname and use that by default, but the
user can always specify pkgname_login_class (or just _class maybe?) as
some other value.

> 
>> 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.
> 
> Then service would just use the above program to get sane defaults...
> 


-- 
Allan Jude

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20150910/4dd412f0/attachment.bin>