Date: Tue, 28 May 1996 04:45:27 +1000 From: Bruce Evans <bde@zeta.org.au> To: joerg_wunsch@uriah.heep.sax.de, mmead@Glock.COM Cc: freebsd-hackers@FreeBSD.org Subject: Re: CHILD_MAX Message-ID: <199605271845.EAA13670@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> > Does anyone know why CHILD_MAX for the kernel and CHILD_MAX >> > in the /usr/include/sys/syslimits.h are different (128 and 40 >> > respectively)? I'm running into the problem of having too few It should be the same. >> > processes available. If I redefine the define in syslimits.h to >> > 128 will I be able to run right away, or am I correct in >> > presuming that I'm going to have to rebuild things? What all >> > will I have to rebuild? Who knows? CHILD_MAX is bogus and shouldn't be used. You have to rebuild anything that actually uses it. Netscape perhaps. The bogusness is actually a littly different for foreign applications. The value of CHILD_MAX depends on the application and the foreign system's headers at the time the application was compiled. >> The correct way is >> options "CHILD_MAX=128" >> and rebuild the kernel. Incorrect. > I thought I'd seen someone say that this didn't work. >Are you sure that CHILD_MAX=128 in the kernel is not the default? >Does syslimits.h really not need to be changed from 40? Changing it in the kernel changes the default value and makes the value in syslimits.h more bogus than before. The fixed value is only correct if it is never changed. It can be changed using setrlimit(2) or using various shell limit commands. >> I've once got the idea to make this limit dynamic, depending on the >> size of the machine (amount of physical memory, speed of CPU), since It's not a limit. It is the default value for a limit. The limit is actually maxprocperuid, although getrlimit(2) reports that the maximum for the limit is initially RLIMIT_INFINITY = 0x7fffffffffffffff. Setting the limit (even to the same value) changes the maximum limit to maxprocperuid. >> it's mostly there to prevent denial of resource attacks (like the >> ``fork trap''). The current static limit doesn't fullfill this, it's >> too high for a 386/16 w/ 4 MB RAM, and far too low for wcarchive. The number of processes isn't a very good measure of the resource usage. I think I'd like per-user space (mostly swap space) and time (%cpu) resources. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605271845.EAA13670>