On 2/3/06, Per Jessen <per@computer.org> wrote:
Steve Graegert wrote:
I just ran the above via a remote konsole, and my 2-way machine certainly _appears_ to be locked up. I'll have to make my way to the computer-room to check out the local console.
Sorry, to hear that. I've used this code for years in trainings on a couple of platforms. Never tried that on an Intel box running Linux prior to 2.6. Can hardly believe that 2.4 can be compromised that easily :-
What's interesting is - it reported CHILD_MAX = 999, yet your bit of code was allowed to start 7000+ processes? (see my other posting) This is not an area I've ever looked into - do I need to enable something or other in order to have a cap on the number of processes?
There are two settings which affect the maximum number of procs per real user id: 1. /etc/security/limits.conf tells the kernel what and how much resources a user/group can use on a particular system. It can be seen as a quota. 2. The shells ulimit (man bash [on my 9.3]) determines the upper limit for certain resources like memory, processes and the like. Some shells do not support for configuration of all resources (like sh). 'ulimit -u' tells gives 6143 on my system, thus allowing 6143 processes per user. When I disable any limits on this resource in limits.conf (meaning unlimited) I am able to create this number of procs (see my previous posts). I usually limit this resource to 64 for regular users and bash was not able to create more than 64 processes. ulimit does not override limits.conf The sysconf(_SC_CHILD_MAX) thing is a POSIX limit that can be overridden by the kernel and application writer (it's intended for developers to encourage them to write portable code). As written earlier, from the mathematical POV, systems support billions of processes, which does not mean that they are able to handle them. If someone wants to find a reasonable max value for the number of procs per real user id, one should query sysconf and use the returned value as the maximum setting. 'Maximum' is by no means optimal, it's just an upper limit. \Steve -- Steve Graegert <graegerts@gmail.com> Software Consultant {C/C++ && Java && .NET} Office: +49 9131 7123988 Mobile: +49 1520 9289212