Date: Sun, 5 Feb 1995 18:56:38 +1100 From: Bruce Evans <bde@zeta.org.au> To: elh@p5.spnet.com, freebsd-hackers@FreeBSD.org Cc: elh@spnet.com Subject: Re: kernel limits Message-ID: <199502050756.SAA12171@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
> 1) bump /usr/src/sys/sys/param.h:MAXSYMLNK from 8 to > something reasonable, such as 32. This limit should probably be changeable using sysctl. > 2) bump up CHILD_MAX from 40 to something reasonable, > say 128. > why: i've compiled large software systems that spawn > a deep series of subshells and (then do final makes) and > these can frequently run into MAXUPRC, which is set to > CHILD_MAX. also, simulating make-called-tools from other CHILD_MAX is bogus. It is only used to report a bogus limit to applications in <limits.h> and to initialize MAXUPRC. MAXUPRC is only the _initial_ value for the _current_ (soft) process limit. The actual limit is the _hard_ process limit, which is initially `maxproc' but can be reduced by applications. `maxproc' itself can be changed using `sysctl -w kern.maxproc=whatever'. Applications that need a larger limit should use setrlimit() to increase their soft limit. Systems that need a larger limit should use sysctl in /etc/rc.local to increase `maxproc'. There seem to be some coherency problems in practice. Changing limits with sysctl has no effect on previously set rlimits. This seems best - a process that has used getrlimit() or setrlimit should not have the limits changed beneath it. Rlimits are inherited, so changing limits with sysctl has on effect on the rlimits for subsequently forked processes, unless setrlimit() is used; however, the maxproc limit is enforced as well as rlimit_cur[RLIMIT_NPROC], so the unchanged rlimits may be too large. Process limits apply to all processes with the same uid. This allows a deeply nested process to screw up top-level processes by increasing its process limit and forking a lot of processes - the limit for top-level processes isn't changed so they may not be able to fork. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199502050756.SAA12171>