Ulimit

A single user who starts too many processes can make a system unusable for everyone else. A fork bomb -- a denial of service attack in which a process continually replicates itself until available resources are depleted -- is a worst case of this.

 To see the limits associate with your login, use the command ulimit -a. If you're using a regular user account, you will likely see something like this:

$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 32767
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 50
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

We cannot create core dumps here because out max core file size is zero (i.e no data, no coredump)

If a process that you are running aborts, no core file is going to be dropped into your home directory. As long as the core file size is set to zero, core dumps are not allowed.

This makes sense for most users since they probably wouldn't do anything more with a core dump other than erase it, but if you need a core dump to debug problems you are running into with an application, you might want to set your core file size to unlimited -- and maybe you can.

$ ulimit -c ulimited $ ulimit -c unlimited

If you are managing a server and want to turn on the ability to generate core dumps for all of your users -- perhaps they're developers are really need to be able to analyze these core dumps, you have to switch user to root and edit your /etc/security/limits.conf (Linux) or make changes in your /etc/system (Solaris) file.

If, on the other hand, you are managing a server and don't want any of your users able to generate core dumps regardless of how much they'd like to sink their teeth into one, you can set a limit of 0 in your limits.conf.

Another limit that is often enforced is one that limits the number of processes that an individual can run. The ulimit option used for this is -u. You can look at your limit as we did above with the ulimit -a command or show just the "nproc" limit with the command ulimit -u.

$ ulimit -u 50

Once again, your users can change their limits with another ulimit command -- ulimit -u 100 -- unless, of course, they can't. If you have limited them to 50 processes in the limits.conf or system file, they will get an error like this when they try to increase their limits:

$ ulimit -u 100 -bash: ulimit: max user processes: cannot modify limit: Operation not permitted 

Limits can also be set up by group so that you can, say, give developers the ability to run more processes than managers. Lines like these in your limits.conf file would do that:

@managers hard nproc 50 
@developers hard nproc 200 

If you want to limit the number of open files, you just use a different setting.

@managers hard nofile 2048
@developers hard nofile 8192
sbob hard nofile 8192 

Here we've given two groups and one individual increases in their open files limits. These all set hard limits. If you set soft limits as well, the users will get warnings when they reach the lower limit.

@developers soft nofile 2048
@developers hard nofile 8192