If you have users, the ability to limit their system use may have come to mind. FreeBSD provides several ways an administrator can limit the amount of system resources an individual may use. These limits are divided into two sections: disk quotas, and other resource limits.
Disk quotas limit disk usage to users, and they provide a way to quickly check that usage without calculating it every time. Quotas are discussed in Section 19.15.
The other resource limits include ways to limit the amount of CPU, memory, and other resources a user may consume. These are defined using login classes and are discussed here.
Login classes are defined in /etc/login.conf. The precise semantics are beyond the scope of this section, but are described in detail in the login.conf(5) manual page. It is sufficient to say that each user is assigned to a login class (default by default), and that each login class has a set of login capabilities associated with it. A login capability is a name=value pair, where name is a well-known identifier and value is an arbitrary string processed accordingly depending on the name. Setting up login classes and capabilities is rather straight-forward and is also described in login.conf(5).
Note: The system does not normally read the configuration in /etc/login.conf directly, but reads the database file /etc/login.conf.db which provides faster lookups. To generate /etc/login.conf.db from /etc/login.conf, execute the following command:
# cap_mkdb /etc/login.conf
Resource limits are different from plain vanilla login capabilities in two ways. First, for every limit, there is a soft (current) and hard limit. A soft limit may be adjusted by the user or application, but may be no higher than the hard limit. The latter may be lowered by the user, but never raised. Second, most resource limits apply per process to a specific user, not the user as a whole. Note, however, that these differences are mandated by the specific handling of the limits, not by the implementation of the login capability framework (i.e., they are not really a special case of login capabilities).
And so, without further ado, below are the most commonly used resource limits (the rest, along with all the other login capabilities, may be found in login.conf(5)).
The limit on the size of a core file generated by a program is, for obvious reasons, subordinate to other limits on disk usage (e.g., filesize, or disk quotas). Nevertheless, it is often used as a less-severe method of controlling disk space consumption: since users do not generate core files themselves, and often do not delete them, setting this may save them from running out of disk space should a large program (e.g., emacs) crash.
This is the maximum amount of CPU time a user's process may consume. Offending processes will be killed by the kernel.
Note: This is a limit on CPU time consumed, not percentage of the CPU as displayed in some fields by top(1) and ps(1). A limit on the latter is, at the time of this writing, not possible, and would be rather useless: a compiler—probably a legitimate task—can easily use almost 100% of a CPU for some time.
This is the maximum size of a file the user may possess. Unlike disk quotas, this limit is enforced on individual files, not the set of all files a user owns.
This is the maximum number of processes a user may be running. This includes
foreground and background processes alike. For obvious reasons, this may not be
larger than the system limit specified by the kern.maxproc sysctl(8). Also note
that setting this too small may hinder a user's productivity: it is often
useful to be logged in multiple times or execute pipelines. Some tasks, such as
compiling a large program, also spawn multiple processes (e.g., make(1), cc(1), and other
intermediate preprocessors).
This is the maximum amount a memory a process may have requested to be locked into main memory (e.g., see mlock(2)). Some system-critical programs, such as amd(8), lock into main memory such that in the event of being swapped out, they do not contribute to a system's thrashing in time of trouble.
This is the maximum amount of memory a process may consume at any given time. It includes both core memory and swap usage. This is not a catch-all limit for restricting memory consumption, but it is a good start.
This is the maximum amount of files a process may have open. In FreeBSD, files
are also used to represent sockets and IPC channels; thus, be careful not to set
this too low. The system-wide limit for this is defined by the kern.maxfiles sysctl(8).
This is the limit on the amount of network memory, and thus mbufs, a user may consume. This originated as a response to an old DoS attack by creating a lot of sockets, but can be generally used to limit network communications.
This is the maximum size a process' stack may grow to. This alone is not sufficient to limit the amount of memory a program may use; consequently, it should be used in conjunction with other limits.
There are a few other things to remember when setting resource limits. Following are some general tips, suggestions, and miscellaneous comments.
Processes started at system startup by /etc/rc are assigned to the daemon login class.
Although the /etc/login.conf that comes with the system is a good source of reasonable values for most limits, only you, the administrator, can know what is appropriate for your system. Setting a limit too high may open your system up to abuse, while setting it too low may put a strain on productivity.
Users of the X Window System (X11) should probably be granted more resources than other users. X11 by itself takes a lot of resources, but it also encourages users to run more programs simultaneously.
Remember that many limits apply to individual processes, not the user as a whole. For
example, setting openfiles to 50 means that each
process the user runs may open up to 50 files. Thus, the gross amount of files a user may
open is the value of openfiles multiplied by the value of maxproc. This also applies to memory consumption.
For further information on resource limits and login classes and capabilities in general, please consult the relevant manual pages: cap_mkdb(1), getrlimit(2), login.conf(5).