Date: Mon, 27 May 1996 15:04:21 -0400 (EDT) From: "matthew c. mead" <mmead@Glock.COM> To: bde@zeta.org.au (Bruce Evans) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.org Subject: Re: CHILD_MAX Message-ID: <199605271904.PAA06684@Glock.COM> In-Reply-To: <199605271845.EAA13670@godzilla.zeta.org.au> from "Bruce Evans" at May 28, 96 04:45:27 am
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans writes: > >> > 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. It isn't in 2.1R. > >> > 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. I thought that a system call (fork()) was the only limiting factor, and that the kernel would return an error if the user has too many processes. Am I wrong in this assumption? Does libc check before making the fork() system call? All I really want here is a simple way to increase the number of processes for a user. I'm running into the limit of 40, and I need to expand that. I don't think this should be so hard. Will changing the kernel affect things that run? Will I also have to change syslimits.h and then rebuild everything????????? > >> 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. So should it be changed to the same thing in the kernel and syslimits.h? > >> 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. Well, it's *obviously* not letting me run that many processes, as I'm getting denied at 40. > >> 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. Well, I agree with you there, but what I'm trying to find out is not what is a good resource usage algorithm, but rather, how do I allow more than 40 processes per user. -matt -- Matthew C. Mead mmead@Glock.COM http://www.goof.com/~mmead/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605271904.PAA06684>