1GETRLIMIT(2) Linux Programmer's Manual GETRLIMIT(2)
2
6 getrlimit, setrlimit, prlimit - get/set resource limits
7
9 #include <sys/resource.h>
10 int getrlimit(int resource, struct rlimit *rlim);
12 int setrlimit(int resource, const struct rlimit *rlim);
13 int prlimit(pid_t pid, int resource, const struct rlimit *new_limit,
15 struct rlimit *old_limit);
16 Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
18 prlimit():
20 _GNU_SOURCE
21
23 The getrlimit() and setrlimit() system calls get and set resource lim‐
24 its. Each resource has an associated soft and hard limit, as defined
25 by the rlimit structure:
26 struct rlimit {
28 rlim_t rlim_cur; /* Soft limit */
29 rlim_t rlim_max; /* Hard limit (ceiling for rlim_cur) */
30 };
31 The soft limit is the value that the kernel enforces for the corre‐
33 sponding resource. The hard limit acts as a ceiling for the soft
34 limit: an unprivileged process may set only its soft limit to a value
35 in the range from 0 up to the hard limit, and (irreversibly) lower its
36 hard limit. A privileged process (under Linux: one with the
37 CAP_SYS_RESOURCE capability in the initial user namespace) may make ar‐
38 bitrary changes to either limit value.
39 The value RLIM_INFINITY denotes no limit on a resource (both in the
41 structure returned by getrlimit() and in the structure passed to setr‐
42 limit()).
43 The resource argument must be one of:
45 RLIMIT_AS
47 This is the maximum size of the process's virtual memory (ad‐
48 dress space). The limit is specified in bytes, and is rounded
49 down to the system page size. This limit affects calls to
50 brk(2), mmap(2), and mremap(2), which fail with the error ENOMEM
51 upon exceeding this limit. In addition, automatic stack expan‐
52 sion fails (and generates a SIGSEGV that kills the process if no
53 alternate stack has been made available via sigaltstack(2)).
54 Since the value is a long, on machines with a 32-bit long either
55 this limit is at most 2 GiB, or this resource is unlimited.
56 RLIMIT_CORE
58 This is the maximum size of a core file (see core(5)) in bytes
59 that the process may dump. When 0 no core dump files are cre‐
60 ated. When nonzero, larger dumps are truncated to this size.
61 RLIMIT_CPU
63 This is a limit, in seconds, on the amount of CPU time that the
64 process can consume. When the process reaches the soft limit,
65 it is sent a SIGXCPU signal. The default action for this signal
66 is to terminate the process. However, the signal can be caught,
67 and the handler can return control to the main program. If the
68 process continues to consume CPU time, it will be sent SIGXCPU
69 once per second until the hard limit is reached, at which time
70 it is sent SIGKILL. (This latter point describes Linux behav‐
71 ior. Implementations vary in how they treat processes which
72 continue to consume CPU time after reaching the soft limit.
73 Portable applications that need to catch this signal should per‐
74 form an orderly termination upon first receipt of SIGXCPU.)
75 RLIMIT_DATA
77 This is the maximum size of the process's data segment (initial‐
78 ized data, uninitialized data, and heap). The limit is speci‐
79 fied in bytes, and is rounded down to the system page size.
80 This limit affects calls to brk(2), sbrk(2), and (since Linux
81 4.7) mmap(2), which fail with the error ENOMEM upon encountering
82 the soft limit of this resource.
83 RLIMIT_FSIZE
85 This is the maximum size in bytes of files that the process may
86 create. Attempts to extend a file beyond this limit result in
87 delivery of a SIGXFSZ signal. By default, this signal termi‐
88 nates a process, but a process can catch this signal instead, in
89 which case the relevant system call (e.g., write(2), trun‐
90 cate(2)) fails with the error EFBIG.
91 RLIMIT_LOCKS (Linux 2.4.0 to 2.4.24)
93 This is a limit on the combined number of flock(2) locks and fc‐
94 ntl(2) leases that this process may establish.
95 RLIMIT_MEMLOCK
97 This is the maximum number of bytes of memory that may be locked
98 into RAM. This limit is in effect rounded down to the nearest
99 multiple of the system page size. This limit affects mlock(2),
100 mlockall(2), and the mmap(2) MAP_LOCKED operation. Since Linux
101 2.6.9, it also affects the shmctl(2) SHM_LOCK operation, where
102 it sets a maximum on the total bytes in shared memory segments
103 (see shmget(2)) that may be locked by the real user ID of the
104 calling process. The shmctl(2) SHM_LOCK locks are accounted for
105 separately from the per-process memory locks established by
106 mlock(2), mlockall(2), and mmap(2) MAP_LOCKED; a process can
107 lock bytes up to this limit in each of these two categories.
108 In Linux kernels before 2.6.9, this limit controlled the amount
110 of memory that could be locked by a privileged process. Since
111 Linux 2.6.9, no limits are placed on the amount of memory that a
112 privileged process may lock, and this limit instead governs the
113 amount of memory that an unprivileged process may lock.
114 RLIMIT_MSGQUEUE (since Linux 2.6.8)
116