On 2/3/06, Per Jessen
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