---

   vlimit    ( 3 )

---

Ошибки (баги) (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().