>> > > remove that rlimit code, rc.d and login classes do it much betterer these >> > > days. screaming bob ok claudio >> > > >> > >> > Similar code is in a few other places, if it's going from bgpd it >> > should be zapped there too. Should we add login.conf sections for >> > bgpd, ftp-proxy, inetd, relayd, smtpd and spamd, or just bump >> > the default openfiles-cur for daemon to 512 or something and >> > maybe add sections for a few daemons that might still have >> > trouble with 512 (partly to help with the limits, and partly >> > to show people how it's done)? >> >> At least spamd does set the openfiles-cur based on the maximum number of >> connections a users specifies. That code is OK. Daemons setting the limit >> to infinity on the otherhands are not. > > Should we give an example for at least bgpd? 128 FDs is a bit > tight for a peering router and we could do with having at least > one daemon shown in login.conf as an example of how to configure > this. > > > Index: login.conf.in > =================================================================== > RCS file: /cvs/src/etc/login.conf.in,v > retrieving revision 1.3 > diff -u -p -r1.3 login.conf.in > --- login.conf.in 17 Dec 2010 05:33:06 -0000 1.3 > +++ login.conf.in 26 Jul 2011 12:31:02 -0000 > @@ -84,3 +84,10 @@ authpf:\ > :welcome=/etc/motd.authpf:\ > :shell=/usr/sbin/authpf:\ > :tc=default: > + > +# > +# Override resource limits for certain daemons started by rc.d(8) > +# > +bgpd:\ > + :openfiles-cur=512:\ > + :tc=daemon:
very elegant! IMHO login.conf should be set based on a combination of what you have enabled (pf ruleset is huge, bgpd, spamd etc) and your hardware. can this be shifted to sysmerge, so sysmerge can periodically make a decision when machine configuration changes it will automagically bump limits?
