получить / установить ограничения ресурсов (get/set resource limits)
Ошибки (баги) (Bugs)
In older Linux kernels, the SIGXCPU and SIGKILL signals delivered
when a process encountered the soft and hard RLIMIT_CPU limits
were delivered one (CPU) second later than they should have been.
This was fixed in kernel 2.6.8.
In 2.6.x kernels before 2.6.17, a RLIMIT_CPU limit of 0 is
wrongly treated as "no limit" (like RLIM_INFINITY). Since Linux
2.6.17, setting a limit of 0 does have an effect, but is actually
treated as a limit of 1 second.
A kernel bug means that RLIMIT_RTPRIO does not work in kernel
2.6.12; the problem is fixed in kernel 2.6.13.
In kernel 2.6.12, there was an off-by-one mismatch between the
priority ranges returned by getpriority(2) and RLIMIT_NICE. This
had the effect that the actual ceiling for the nice value was
calculated as 19 - rlim_cur. This was fixed in kernel 2.6.13.
Since Linux 2.6.12, if a process reaches its soft RLIMIT_CPU
limit and has a handler installed for SIGXCPU, then, in addition
to invoking the signal handler, the kernel increases the soft
limit by one second. This behavior repeats if the process
continues to consume CPU time, until the hard limit is reached,
at which point the process is killed. Other implementations do
not change the RLIMIT_CPU soft limit in this manner, and the
Linux behavior is probably not standards conformant; portable
applications should avoid relying on this Linux-specific
behavior. The Linux-specific RLIMIT_RTTIME limit exhibits the
same behavior when the soft limit is encountered.
Kernels before 2.4.22 did not diagnose the error EINVAL for
setrlimit() when rlim->rlim_cur was greater than rlim->rlim_max.
Linux doesn't return an error when an attempt to set RLIMIT_CPU
has failed, for compatibility reasons.
Representation of "large" resource limit values on 32-bit platforms
The glibc getrlimit() and setrlimit() wrapper functions use a
64-bit rlim_t data type, even on 32-bit platforms. However, the
rlim_t data type used in the getrlimit() and setrlimit() system
calls is a (32-bit) unsigned long. Furthermore, in Linux, the
kernel represents resource limits on 32-bit platforms as unsigned
long. However, a 32-bit data type is not wide enough. The most
pertinent limit here is RLIMIT_FSIZE, which specifies the maximum
size to which a file can grow: to be useful, this limit must be
represented using a type that is as wide as the type used to
represent file offsets—that is, as wide as a 64-bit off_t
(assuming a program compiled with _FILE_OFFSET_BITS=64).
To work around this kernel limitation, if a program tried to set
a resource limit to a value larger than can be represented in a
32-bit unsigned long, then the glibc setrlimit() wrapper function
silently converted the limit value to RLIM_INFINITY. In other
words, the requested resource limit setting was silently ignored.
Since version 2.13, glibc works around the limitations of the
getrlimit() and setrlimit() system calls by implementing
setrlimit() and getrlimit() as wrapper functions that call
prlimit().
