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 18.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)).
coredumpsize
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.
cputime
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.
filesize
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.
maxproc
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.maxprocsysctl(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).
memorylocked
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
trashing in time of trouble.
memoryuse
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.
openfiles
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.maxfilessysctl(8).
sbsize
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.
stacksize
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).
