Wolfram Gloger wrote:
[ ....] In my documentation, ulimit sets a limit for the *current* process, not for the whole system.I know, but see /etc/initscript. Together with the number of processes (also ulimited), it effectively is a limit for the system. Not the one you like, obviously, but nevertheless a functional one.
I am not sure how one could describe a system crippled in this way as "functional". The limit itself would indeed be "functional", but, to my best understanding, only in the same way that throwing the computer off of the roof of a building would also function to limit the memory consumption of processes running on it. Allow me to explain:
[begin historical analogy]Using ulimit in this way would give one an environment a bit like that of IBM's antique VM operating system for their 360 series of computers, except even worse. In VM, every user had his own small "virtual disk", and the entire real disk was partitioned among them. So, 200 users on a system with 50 MB of disk space meant each user got exactly 250 KB of disk space, and some users would run out of disk space even if the system disk (seen as an aggregate) was only a few percent full.
[end historical analogy]Remember, /etc/initscript doesn't let me set limits on a per-user basis. Also, remember that ulimit for the number of processes applies only on a per-user basis, not as a pool across the entire number of processes.
So let's see. The system I'm currently running this on (a laptop) has 1 GB of memory, 23 users in /etc/passwd. The user with the most processes (ignoring kernel processes like [kapmd] that don't take up memory) currently has 61 processes. If we take these as hard limits, then 1 GB / (61 * 23) = 747 KB of memory per process. That isn't enough even to run bash, xterm, or dhclient, to say nothing of the X server or Mozilla or Emacs.
[...] > For me the alternative is
clear: either enjoy the advantages and disadvantages of overcommitment _or_ use "ulimit -v".
The second of those appears impractical, for the reasons I argue above.
Regards, Wolfram.
Cordially yours, --Steve -- Steven Augart Jikes RVM, a free, open source, Virtual Machine: http://oss.software.ibm.com/jikesrvm