svn commit: r287606 - head/sys/kern

[John-Mark Gurney]

Eric van Gyzen wrote this message on Thu, Sep 10, 2015 at 14:56 -0500:
> On 09/10/2015 12: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.
> 
> We could--and should--do both, because they're both good ideas.
> 
> >> 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?
> 
> See limits(1).  The apache rc.d script uses it, along with some related
> rc.conf variables.

So, one issue w/ limits is that it only does the limits side of
things, not environment or cpusets...  see:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=161401

limits doesn't address PATH and other environment variables...

We should have rc.subr setup the environment completely when executing
the daemon/scripts instead of depending upon any of this..

It turns out that init doesn't setup the environment vars provided by
login.config either...

> >> * 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?
> > 
> >> 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...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."