FreeBSD provides several methods for an administrator to limit the amount of system resources an individual may use. These limits are discussed in two sections: disk quotas and other resource limits.
Disk quotas limit the amount of disk space available to users and provide a way to quickly check that usage without calculating it every time. Quotas are discussed in Section 19.13, “File System Quotas”.
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
and are described in detail
in login.conf(5). Each user account is assigned to a login
class, default
by default, and each login
class has a set of login capabilities associated with it. A
login capability is a
pair, where name
=value
name
is a well-known
identifier and value
is an arbitrary
string which is processed accordingly depending on the
name
. Setting up login classes and
capabilities is rather straightforward and is also described in
login.conf(5).
FreeBSD does not normally read the configuration in
/etc/login.conf
directly, but instead
reads the /etc/login.conf.db
database
which provides faster lookups. Whenever
/etc/login.conf
is edited, the
/etc/login.conf.db
must be updated by
executing the following command:
#
cap_mkdb /etc/login.conf
Resource limits differ from the default 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 not be set higher than the hard limit. The hard limit may be lowered by the user, but can only be raised by the superuser. Second, most resource limits apply per process to a specific user, not to the user as a whole. These differences are mandated by the specific handling of the limits, not by the implementation of the login capability framework.
Below are the most commonly used resource limits. The rest of the limits, along with all the other login capabilities, can be found in login.conf(5).
coredumpsize
The limit on the size of a core file generated by a
program is subordinate to other limits on disk usage, such
as filesize
, or disk quotas.
This limit 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 crash.
cputime
The maximum amount of CPU time a user's process may consume. Offending processes will be killed by the kernel.
filesize
The maximum size of a file the user may own. Unlike disk quotas, this limit is enforced on individual files, not the set of all files a user owns.
maxproc
The maximum number of processes a user can run. This
includes foreground and background processes. This limit
may not be larger than the system limit specified by the
kern.maxproc
sysctl(8). Setting
this limit too small may hinder a user's productivity as
it is often useful to be logged in multiple times or to
execute pipelines. Some tasks, such as compiling a large
program, spawn multiple processes and other intermediate
preprocessors.
memorylocked
The maximum amount of memory a process may request to be locked into main memory using mlock(2). Some system-critical programs, such as amd(8), lock into main memory so that if the system begins to swap, they do not contribute to disk thrashing.
memoryuse
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 is a good start.
openfiles
The maximum number of files a process may have open.
In FreeBSD, files are used to represent sockets and IPC
channels, so be careful not to set this too low. The
system-wide limit for this is defined by the
kern.maxfiles
sysctl(8).
sbsize
The limit on the amount of network memory, and thus mbufs, a user may consume in order to limit network communications.
stacksize
The maximum size of a process stack. This alone is not sufficient to limit the amount of memory a program may use so 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, they may not be appropriate for every
system. Setting a limit too high may open the system up to
abuse, while setting it too low may put a strain on
productivity.
Users of Xorg should probably be granted more resources than other users. Xorg by itself takes a lot of resources, but it also encourages users to run more programs simultaneously.
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. The total 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, refer to cap_mkdb(1), getrlimit(2), and login.conf(5).
All FreeBSD documents are available for download at http://ftp.FreeBSD.org/pub/FreeBSD/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.