UsingResourceLimits102012-09-03 08:46:15ClintonEbadi92011-04-22 23:03:34ClintonEbadiRevert to revision 7.82011-04-21 17:32:44210.253.49.142oaccv5 <a href="http://xebkqvcikfmi.com/">xebkqvcikfmi</a>72011-04-21 05:48:09ClintonEbadiRevert to revision 4.62011-04-21 05:37:1967.216.175.132That's way more clever than I was exepticng. Thanks!52011-04-21 03:08:32114-32-167-53.HINET-IP.hinet.netI'm not eiasly impressed. . . but that's impressing me! :)42009-08-22 21:54:12RichardDarstfix markup32008-07-07 04:28:04localhostconverted to 1.6 markup22005-09-12 11:43:54AdamChlipalaChanged output to be actual soft limits that we're using12005-09-12 11:27:44AdamChlipalaTo prevent users from monopolizing system resources with runaway processes, we impose ulimits in a way that will lead to your processes dying mysteriously if they try to exceed them. You can see what limits are being imposed in your current login by running the following command, with output shown: These limits are known as soft limits. Similarly, you can see your hard limits by running ulimit -aH
. Soft limits are the limits that actually apply to your processes at a given time. You have the option to increase your soft limits to any values no greater than your hard limits. For instance, if you really need to run 21 processes at once instead of just 20, you can do this, because your hard limit is probably 50. The proper command is: The -S
indicates that you are setting a soft limit, and u
is the name of a resource limit kind, taken from the output above. You can even decrease your available resources, to put yourself in a self-imposed sandbox. For instance, you can lower your stack size hard limit to 1000 by running: How Draconian! Why do we have these limits??On our old server, we had multiple instances of users running benign yet out-of-control processes that ended up allocating all available memory. Shared daemons, like our web and mail servers, would then crash when trying to allocate memory, creating denial-of-service for everyone. The ssh daemon wasn't even able to work properly without available memory, so we sometimes needed to ask the techs at our hosting facility to reboot the server for us! It's always better safe than sorry when it comes to protecting users from breaking other users' services. CategoryOutdated