> For the complete documentation index, see [llms.txt](https://book.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://book.bsdcn.org/ask/flat/chapter-29-security/di-29.3-jie-zi-yuan-xian-zhi.md). # 29.3 Resource Limits FreeBSD provides two mechanisms for resource limits: **/etc/login.conf** static resource limits and `rctl` dynamic resource limits. This section presents login class configuration methods and process-level constraint rule definitions respectively. ## Resource Limits In FreeBSD, resource limits refer to mechanisms that control and manage the system resources available to processes and users, preventing a single process or user from consuming excessive resources and avoiding performance degradation or system instability. Resource limits help ensure fair allocation of resources among all active processes and users in the system. FreeBSD provides multiple methods for administrators to limit the amount of system resources available to users. The traditional method is to define login classes by editing the **/etc/login.conf** file. Although this method is still supported, any changes require multiple steps: editing the file, rebuilding the resource database, modifying the **/etc/master.passwd** file, and rebuilding the password database. This process is cumbersome and time-consuming depending on the number of users to configure. In contrast, `rctl` provides a more fine-grained resource limiting mechanism that can also set resource constraints for processes and jails. This section demonstrates both methods for controlling resources, starting with the traditional method. ### Resource Types FreeBSD supports imposing limits on the following resource types: | Type | Description | | ----------------------------------------- | ------------------------------------------------------------------------------- | | cputime | Limits the amount of CPU time a process can consume | | memoryuse / memorylocked | Controls the amount of physical memory / locked memory a process can use | | openfiles | Limits the number of files a process can open simultaneously | | maxproc | Controls the number of processes a user or process can create | | filesize | Limits the maximum size of files a process can create (login.conf only) | | coredumpsize | Controls whether a process can generate core dump files and their size | | datasize / stacksize | Limits the data segment / stack segment size | | vmemoryuse | Limits the total virtual memory usage of a process | | sbsize | Limits socket buffer size (login.conf only) | | pseudoterminals | Limits the number of pseudo-terminals | | swapuse | Limits swap space usage | | umtxp | Limits the maximum number of shared pthread locks per process (login.conf only) | | pipebuf | Limits the maximum size of pipe buffers (login.conf only) | | nthr | Limits the number of threads (`rctl` only) | | wallclock / pcpu | Limits wall clock time / CPU percentage (`rctl` only) | | readbps / writebps / readiops / writeiops | Limits file system read/write rates (`rctl` only) | **Resource Types Table** ### Configuring Login Classes In the traditional method, login classes and their associated resource limits are defined in the **/etc/login.conf** file. Each user account can be assigned to a login class, with `default` being the default class. Each class is associated with a set of login capabilities in the format `name=value` pairs, where **name** is a known identifier and **value** is an arbitrary string processed according to the rules of the corresponding **name**. To configure resource limits, first edit the **/etc/login.conf** file and locate the user class section to be modified. This example assumes a class named `limited`; create it if it does not exist. ```ini limited:\ # User class name :maxproc=50:\ # Set the maximum number of processes (maxproc) for users in the limited class to 50 :tc=default: # This user class inherits the default settings of the default class ``` After modifying **/etc/login.conf**, run `cap_mkdb` to generate the database for FreeBSD to apply these settings: ```sh # cap_mkdb /etc/login.conf ``` `chpass` can switch the class for the target user `ykla`: ```sh # chpass ykla ``` > **Tip** > > Use the command `export EDITOR=ee` to change the default editor from vi to ee for easier operation. This will open a text editor; add the new `limited` class as follows: ```ini #Changing user information for ykla. Login: ykla Password: $6$SqMJXrv5aC6Wq.by$nmbZs078aHNBVyh9noLFouJsGHyFSvQIzH0W4zpdfXuPtGtt.FHgWfXDHVBa Uid [#]: 1001 Gid [# or name]: 1001 Change [month day year]: Expire [month day year]: April 16, 2027 Class: limited Home directory: /home/ykla Shell: /bin/sh Full Name: User & Office Location: Office Phone: Home Phone: Other information: ``` Now users belonging to the `limited` class will have their maximum number of processes limited to 50. Note that the above is merely an example of setting resource limits using **/etc/login.conf**. After modifying **/etc/login.conf**, users must log out and log back in for the changes to take effect. ## Enabling and Configuring Resource Limits The `rctl` command is used to control resource limits, dynamically assigning resource constraints to specific processes or users, regardless of their login class. Before using rctl, it must first be enabled by adding the following line to **/boot/loader.conf** and restarting the system: ```ini kern.racct.enable=1 ``` The kernel tunable `kern.racct.enable=1` enables the rctl feature. Additionally, if persistent rules are predefined in **/etc/rctl.conf**, the following commands can be executed to have them automatically loaded at startup: ```sh # service rctl enable # service rctl start ``` If **/etc/rctl.conf** is empty, `service rctl start` has no practical effect. After this, rctl can be used to set rules for the system. Rule syntax consists of four parts: **subject** (`process`, `user`, `loginclass`, or `jail`), subject-id, resource, and action: ``` subject:subject-id:resource:action=quantity/object ``` Where `object` defines the scope of quantity counting: | Identifier Path | Scope | Description | | --------------- | --------------- | -------------------------------------------------------------- | | `/process` | Per process | Applies resource limits to each individual process separately. | | `/user` | Per user | Applies a unified limit to all processes of the same user. | | `/loginclass` | Per login class | Groups and limits by login class. | | `/jail` | Per Jail | Groups and limits by Jail. | When omitted, the default is the same as the subject. Common available actions: | Action | Description | | ---------- | ------------------------------------------------------------------------------------------- | | `deny` | Denies the resource allocation or operation. | | `log` | Does not block the operation; only logs a warning message to the console. | | `devctl` | Sends an event notification to devd(8), handled by the system device daemon. | | `sig*` | Sends a signal to the violating process (e.g., `sigterm`, `sigkill`, etc.). | | `throttle` | Slows down process execution; only supports `readbps`, `writebps`, `readiops`, `writeiops`. | For example, to constrain user ykla to a maximum of 10 processes: ```sh # rctl -a user:ykla:maxproc:deny=10/user ``` To check applied resource limits, run rctl: ```sh # rctl ``` The output should resemble the following: ``` user:ykla:maxproc:deny=10 ``` Write the rule to the **/etc/rctl.conf** file so it persists after reboot. The format is a single rule without a leading command. For example, the above rule can be added as: ```ini user:ykla:maxproc:deny=10 ``` ## Exercises 1. Set `maxproc` to 50 for a test user class in the **/etc/login.conf** file, then write a simple Shell script to create more than 50 child processes under that class user, observe the system behavior, and analyze the mechanism by which the kernel prevents exceeding the limit. 2. Use `limits -a` to view all resource limits of the current Shell, compare these limits with the output of `sysctl kern.maxproc`, and explain the relationship between user-level limits and system-wide upper bounds. 3. Given that the fork bomb `:(){ :|:& };:` can bring down an unrestricted system, design an experimental approach to prevent such issues. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://book.bsdcn.org/ask/flat/chapter-29-security/di-29.3-jie-zi-yuan-xian-zhi.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.