On 2/3/06, Greg Wallace <gregwallace@fastmail.fm> wrote:
On Friday, February 03, 2006 @ 4:11 AM, Steve Graegert wrote:
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
Wow! I had wanted to increase the max number of files and max processes on my 2 user accounts in the past and, from reading on this list, had gotten the impression that that had to be done by changing kernel parameters and recompiling it. This was back under 8.1 Pro. I needed certain processes to start with higher limits than the defaults, so I ended up with a work-around where I actually used a su -C to do a quick switch to root to start those processes there, where I could up the limits. I just tested setting those limits in limits.conf and it appears to have worked like a champ! Has this capability only come along with more recent versions of SuSE, or was it around back in 8.1 and I just didn't dig it out?
This functionality is relatively old (first seen in 2002 bundled in a PAM package). I don't know what's its origin. \Steve -- Steve Graegert <graegerts@gmail.com> Software Consultant {C/C++ && Java && .NET} Office: +49 9131 7123988 Mobile: +49 1520 9289212