() — MISC. REFERENCE MANUAL PAGES
NAME
getrlimit, setrlimit − control maximum system resource consumption
SYNOPSIS
#include <sys/time.h>
#include <sys/resource.h>
int getrlimit(int resource, struct rlimit ∗rlp);
int setrlimit(int resource, const struct rlimit ∗rlp);
DESCRIPTION
Limits on the consumption of a variety of system resources by a process and each process it creates may be obtained with getrlimit and set with setrlimit.
Each call to either getrlimit or setrlimit identifies a specific resource to be operated upon as well as a resource limit. A resource limit is a pair of values: one specifying the current (soft) limit, the other a maximum (hard) limit. Soft limits may be changed by a process to any value that is less than or equal to the hard limit. A process may (irreversibly) lower its hard limit to any value that is greater than or equal to the soft limit. Only a process with an effective user ID of superuser can raise a hard limit. Both hard and soft limits can be changed in a single call to setrlimit subject to the constraints described above. Limits may have an “infinite” value of RLIM_INFINITY. rlp is a pointer to struct rlimit that includes the following members:
rlim_trlim_cur;/∗ current (soft) limit ∗/
rlim_trlim_max;/∗ hard limit ∗/
rlim_t is an arithmetic data type to which objects of type int, size_t, and off_t can be cast without loss of information.
The possible resources, their descriptions, and the actions taken when current limit is exceeded, are summarized in the following table:
| Resources | Description | Action | |
| RLIMIT_CORE | The maximum size of a core file in bytes that may be created by a process. A limit of 0 will prevent the creation of a core file. | The writing of a core file will terminate at this size. | |
| RLIMIT_CPU | The maximum amount of CPU time in seconds used by a process. | SIGXCPU is sent to the process. If the process is holding or ignoring SIGXCPU, the behavior is scheduling class defined. | |
| RLIMIT_DATA | The maximum size of a process’s heap in bytes. | brk(2) will fail with errno set to ENOMEM. | |
| RLIMIT_FSIZE | The maximum size of a file in bytes that may be created by a process. A limit of 0 will prevent the creation of a file. | SIGXFSZ is sent to the process. If the process is holding or ignoring SIGXFSZ, continued attempts to increase the size of a file beyond the limit will fail with errno set to EFBIG. | |
| RLIMIT_NOFILE | The maximum number of open file descriptors that the process can have. | Functions that create new file descriptors will fail with errno set to EMFILE. | |
| RLIMIT_STACK | The maximum size of a process’s stack in bytes. The system will not automatically grow the stack beyond this limit. | SIGSEGV is sent to the process. If the process is holding or ignoring SIGSEGV, or is catching SIGSEGV and has not made arrangements to use an alternate stack [see sigaltstack(2)], the disposition of SIGSEGV will be set to SIG_DFL before it is sent. | |
| RLIMIT_VMEM | The maximum size of a process’s mapped address space in bytes. | brk(2) and mmap(2) functions will fail with errno set to ENOMEM. In addition, the automatic stack growth will fail with the effects outlined above. |
Because limit information is stored in the per-process information, the shell builtin ulimit must directly execute this system call if it is to affect all future processes created by the shell.
The value of the current limit of the following resources affect these implementation defined constants:
| Limit | Implementation Defined Constant | ||
| RLIMIT_FSIZE | FCHR_MAX | ||
| RLIMIT_NOFILE | OPEN_MAX |
RETURN VALUE
Upon successful completion, the functions getrlimit and setrlimit return a value of 0; otherwise, they return a value of −1 and set errno to indicate an error.
ERRORS
Under the following conditions, the functions getrlimit and setrlimit fail and set errno to:
EINVAL if an invalid resource was specified; or in a setrlimit call, the new rlim_cur exceeds the new rlim_max.
EPERM if the limit specified to setrlimit would have raised the maximum limit value, and the caller is not the superuser