From 399644e47874bff147afb19c89228901ac39340e Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Mon, 15 Apr 2024 21:40:15 +0200 Subject: Adding upstream version 6.05.01. Signed-off-by: Daniel Baumann --- man2/getrlimit.2 | 854 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 854 insertions(+) create mode 100644 man2/getrlimit.2 (limited to 'man2/getrlimit.2') diff --git a/man2/getrlimit.2 b/man2/getrlimit.2 new file mode 100644 index 0000000..afc2c22 --- /dev/null +++ b/man2/getrlimit.2 @@ -0,0 +1,854 @@ +'\" t +.\" Copyright (c) 1992 Drew Eckhardt, March 28, 1992 +.\" and Copyright (c) 2002, 2004, 2005, 2008, 2010 Michael Kerrisk +.\" +.\" SPDX-License-Identifier: Linux-man-pages-copyleft +.\" +.\" Modified by Michael Haardt +.\" Modified 1993-07-23 by Rik Faith +.\" Modified 1996-01-13 by Arnt Gulbrandsen +.\" Modified 1996-01-22 by aeb, following a remark by +.\" Tigran Aivazian +.\" Modified 1996-04-14 by aeb, following a remark by +.\" Robert Bihlmeyer +.\" Modified 1996-10-22 by Eric S. Raymond +.\" Modified 2001-05-04 by aeb, following a remark by +.\" Håvard Lygre +.\" Modified 2001-04-17 by Michael Kerrisk +.\" Modified 2002-06-13 by Michael Kerrisk +.\" Added note on nonstandard behavior when SIGCHLD is ignored. +.\" Modified 2002-07-09 by Michael Kerrisk +.\" Enhanced descriptions of 'resource' values +.\" Modified 2003-11-28 by aeb, added RLIMIT_CORE +.\" Modified 2004-03-26 by aeb, added RLIMIT_AS +.\" Modified 2004-06-16 by Michael Kerrisk +.\" Added notes on CAP_SYS_RESOURCE +.\" +.\" 2004-11-16 -- mtk: the getrlimit.2 page, which formally included +.\" coverage of getrusage(2), has been split, so that the latter +.\" is now covered in its own getrusage.2. +.\" +.\" Modified 2004-11-16, mtk: A few other minor changes +.\" Modified 2004-11-23, mtk +.\" Added notes on RLIMIT_MEMLOCK, RLIMIT_NPROC, and RLIMIT_RSS +.\" to "CONFORMING TO" +.\" Modified 2004-11-25, mtk +.\" Rewrote discussion on RLIMIT_MEMLOCK to incorporate kernel +.\" 2.6.9 changes. +.\" Added note on RLIMIT_CPU error in older kernels +.\" 2004-11-03, mtk, Added RLIMIT_SIGPENDING +.\" 2005-07-13, mtk, documented RLIMIT_MSGQUEUE limit. +.\" 2005-07-28, mtk, Added descriptions of RLIMIT_NICE and RLIMIT_RTPRIO +.\" 2008-05-07, mtk / Peter Zijlstra, Added description of RLIMIT_RTTIME +.\" 2010-11-06, mtk: Added documentation of prlimit() +.\" +.TH getrlimit 2 2023-07-20 "Linux man-pages 6.05.01" +.SH NAME +getrlimit, setrlimit, prlimit \- get/set resource limits +.SH LIBRARY +Standard C library +.RI ( libc ", " \-lc ) +.SH SYNOPSIS +.nf +.B #include +.PP +.BI "int getrlimit(int " resource ", struct rlimit *" rlim ); +.BI "int setrlimit(int " resource ", const struct rlimit *" rlim ); +.PP +.BI "int prlimit(pid_t " pid ", int " resource , +.BI " const struct rlimit *_Nullable " new_limit , +.BI " struct rlimit *_Nullable " old_limit ); +.fi +.PP +.RS -4 +Feature Test Macro Requirements for glibc (see +.BR feature_test_macros (7)): +.RE +.PP +.BR prlimit (): +.nf + _GNU_SOURCE +.fi +.SH DESCRIPTION +The +.BR getrlimit () +and +.BR setrlimit () +system calls get and set resource limits. +Each resource has an associated soft and hard limit, as defined by the +.I rlimit +structure: +.PP +.in +4n +.EX +struct rlimit { + rlim_t rlim_cur; /* Soft limit */ + rlim_t rlim_max; /* Hard limit (ceiling for rlim_cur) */ +}; +.EE +.in +.PP +The soft limit is the value that the kernel enforces for the +corresponding resource. +The hard limit acts as a ceiling for the soft limit: +an unprivileged process may set only its soft limit to a value in the +range from 0 up to the hard limit, and (irreversibly) lower its hard limit. +A privileged process (under Linux: one with the +.B CAP_SYS_RESOURCE +capability in the initial user namespace) +may make arbitrary changes to either limit value. +.PP +The value +.B RLIM_INFINITY +denotes no limit on a resource (both in the structure returned by +.BR getrlimit () +and in the structure passed to +.BR setrlimit ()). +.PP +The +.I resource +argument must be one of: +.TP +.B RLIMIT_AS +This is the maximum size of the process's virtual memory +(address space). +The limit is specified in bytes, and is rounded down to the system page size. +.\" since Linux 2.0.27 / Linux 2.1.12 +This limit affects calls to +.BR brk (2), +.BR mmap (2), +and +.BR mremap (2), +which fail with the error +.B ENOMEM +upon exceeding this limit. +In addition, automatic stack expansion fails +(and generates a +.B SIGSEGV +that kills the process if no alternate stack +has been made available via +.BR sigaltstack (2)). +Since the value is a \fIlong\fP, on machines with a 32-bit \fIlong\fP +either this limit is at most 2\ GiB, or this resource is unlimited. +.TP +.B RLIMIT_CORE +This is the maximum size of a +.I core +file (see +.BR core (5)) +in bytes that the process may dump. +When 0 no core dump files are created. +When nonzero, larger dumps are truncated to this size. +.TP +.B RLIMIT_CPU +This is a limit, in seconds, +on the amount of CPU time that the process can consume. +When the process reaches the soft limit, it is sent a +.B SIGXCPU +signal. +The default action for this signal is to terminate the process. +However, the signal can be caught, and the handler can return control to +the main program. +If the process continues to consume CPU time, it will be sent +.B SIGXCPU +once per second until the hard limit is reached, at which time +it is sent +.BR SIGKILL . +(This latter point describes Linux behavior. +Implementations vary in how they treat processes which continue to +consume CPU time after reaching the soft limit. +Portable applications that need to catch this signal should +perform an orderly termination upon first receipt of +.BR SIGXCPU .) +.TP +.B RLIMIT_DATA +This is the maximum size +of the process's data segment (initialized data, +uninitialized data, and heap). +The limit is specified in bytes, and is rounded down to the system page size. +This limit affects calls to +.BR brk (2), +.BR sbrk (2), +and (since Linux 4.7) +.BR mmap (2), +.\" commits 84638335900f1995495838fe1bd4870c43ec1f67 +.\" ("mm: rework virtual memory accounting"), +.\" f4fcd55841fc9e46daac553b39361572453c2b88 +.\" (mm: enable RLIMIT_DATA by default with workaround for valgrind). +which fail with the error +.B ENOMEM +upon encountering the soft limit of this resource. +.TP +.B RLIMIT_FSIZE +This is the maximum size in bytes of files that the process may create. +Attempts to extend a file beyond this limit result in delivery of a +.B SIGXFSZ +signal. +By default, this signal terminates a process, but a process can +catch this signal instead, in which case the relevant system call (e.g., +.BR write (2), +.BR truncate (2)) +fails with the error +.BR EFBIG . +.TP +.BR RLIMIT_LOCKS " (Linux 2.4.0 to Linux 2.4.24)" +.\" to be precise: Linux 2.4.0-test9; no longer in Linux 2.4.25 / Linux 2.5.65 +This is a limit on the combined number of +.BR flock (2) +locks and +.BR fcntl (2) +leases that this process may establish. +.TP +.B RLIMIT_MEMLOCK +This is the maximum number of bytes of memory that may be locked +into RAM. +This limit is in effect rounded down to the nearest multiple +of the system page size. +This limit affects +.BR mlock (2), +.BR mlockall (2), +and the +.BR mmap (2) +.B MAP_LOCKED +operation. +Since Linux 2.6.9, it also affects the +.BR shmctl (2) +.B SHM_LOCK +operation, where it sets a maximum on the total bytes in +shared memory segments (see +.BR shmget (2)) +that may be locked by the real user ID of the calling process. +The +.BR shmctl (2) +.B SHM_LOCK +locks are accounted for separately from the per-process memory +locks established by +.BR mlock (2), +.BR mlockall (2), +and +.BR mmap (2) +.BR MAP_LOCKED ; +a process can lock bytes up to this limit in each of these +two categories. +.IP +Before Linux 2.6.9, this limit controlled the amount of +memory that could be locked by a privileged process. +Since Linux 2.6.9, no limits are placed on the amount of memory +that a privileged process may lock, and this limit instead governs +the amount of memory that an unprivileged process may lock. +.TP +.BR RLIMIT_MSGQUEUE " (since Linux 2.6.8)" +This is a limit on the number of bytes that can be allocated +for POSIX message queues for the real user ID of the calling process. +This limit is enforced for +.BR mq_open (3). +Each message queue that the user creates counts (until it is removed) +against this limit according to the formula: +.RS 4 +.IP +Since Linux 3.5: +.IP +.in +4n +.EX +bytes = attr.mq_maxmsg * sizeof(struct msg_msg) + + MIN(attr.mq_maxmsg, MQ_PRIO_MAX) * + sizeof(struct posix_msg_tree_node)+ + /* For overhead */ + attr.mq_maxmsg * attr.mq_msgsize; + /* For message data */ +.EE +.in +.IP +Linux 3.4 and earlier: +.IP +.in +4n +.EX +bytes = attr.mq_maxmsg * sizeof(struct msg_msg *) + + /* For overhead */ + attr.mq_maxmsg * attr.mq_msgsize; + /* For message data */ +.EE +.in +.RE +.IP +where +.I attr +is the +.I mq_attr +structure specified as the fourth argument to +.BR mq_open (3), +and the +.I msg_msg +and +.I posix_msg_tree_node +structures are kernel-internal structures. +.IP +The "overhead" addend in the formula accounts for overhead +bytes required by the implementation +and ensures that the user cannot +create an unlimited number of zero-length messages (such messages +nevertheless each consume some system memory for bookkeeping overhead). +.TP +.BR RLIMIT_NICE " (since Linux 2.6.12, but see BUGS below)" +This specifies a ceiling to which the process's nice value can be raised using +.BR setpriority (2) +or +.BR nice (2). +The actual ceiling for the nice value is calculated as +.IR "20\ \-\ rlim_cur" . +The useful range for this limit is thus from 1 +(corresponding to a nice value of 19) to 40 +(corresponding to a nice value of \-20). +This unusual choice of range was necessary +because negative numbers cannot be specified +as resource limit values, since they typically have special meanings. +For example, +.B RLIM_INFINITY +typically is the same as \-1. +For more detail on the nice value, see +.BR sched (7). +.TP +.B RLIMIT_NOFILE +This specifies a value one greater than the maximum file descriptor number +that can be opened by this process. +Attempts +.RB ( open (2), +.BR pipe (2), +.BR dup (2), +etc.) +to exceed this limit yield the error +.BR EMFILE . +(Historically, this limit was named +.B RLIMIT_OFILE +on BSD.) +.IP +Since Linux 4.5, +this limit also defines the maximum number of file descriptors that +an unprivileged process (one without the +.B CAP_SYS_RESOURCE +capability) may have "in flight" to other processes, +by being passed across UNIX domain sockets. +This limit applies to the +.BR sendmsg (2) +system call. +For further details, see +.BR unix (7). +.TP +.B RLIMIT_NPROC +This is a limit on the number of extant process +(or, more precisely on Linux, threads) +for the real user ID of the calling process. +So long as the current number of processes belonging to this +process's real user ID is greater than or equal to this limit, +.BR fork (2) +fails with the error +.BR EAGAIN . +.IP +The +.B RLIMIT_NPROC +limit is not enforced for processes that have either the +.B CAP_SYS_ADMIN +or the +.B CAP_SYS_RESOURCE +capability, +or run with real user ID 0. +.TP +.B RLIMIT_RSS +This is a limit (in bytes) on the process's resident set +(the number of virtual pages resident in RAM). +This limit has effect only in Linux 2.4.x, x < 30, and there +affects only calls to +.BR madvise (2) +specifying +.BR MADV_WILLNEED . +.\" As at Linux 2.6.12, this limit still does nothing in Linux 2.6 though +.\" talk of making it do something has surfaced from time to time in LKML +.\" -- MTK, Jul 05 +.TP +.BR RLIMIT_RTPRIO " (since Linux 2.6.12, but see BUGS)" +This specifies a ceiling on the real-time priority that may be set for +this process using +.BR sched_setscheduler (2) +and +.BR sched_setparam (2). +.IP +For further details on real-time scheduling policies, see +.BR sched (7) +.TP +.BR RLIMIT_RTTIME " (since Linux 2.6.25)" +This is a limit (in microseconds) +on the amount of CPU time that a process scheduled +under a real-time scheduling policy may consume without making a blocking +system call. +For the purpose of this limit, +each time a process makes a blocking system call, +the count of its consumed CPU time is reset to zero. +The CPU time count is not reset if the process continues trying to +use the CPU but is preempted, its time slice expires, or it calls +.BR sched_yield (2). +.IP +Upon reaching the soft limit, the process is sent a +.B SIGXCPU +signal. +If the process catches or ignores this signal and +continues consuming CPU time, then +.B SIGXCPU +will be generated once each second until the hard limit is reached, +at which point the process is sent a +.B SIGKILL +signal. +.IP +The intended use of this limit is to stop a runaway +real-time process from locking up the system. +.IP +For further details on real-time scheduling policies, see +.BR sched (7) +.TP +.BR RLIMIT_SIGPENDING " (since Linux 2.6.8)" +This is a limit on the number of signals +that may be queued for the real user ID of the calling process. +Both standard and real-time signals are counted for the purpose of +checking this limit. +However, the limit is enforced only for +.BR sigqueue (3); +it is always possible to use +.BR kill (2) +to queue one instance of any of the signals that are not already +queued to the process. +.\" This replaces the /proc/sys/kernel/rtsig-max system-wide limit +.\" that was present in Linux <= 2.6.7. MTK Dec 04 +.TP +.B RLIMIT_STACK +This is the maximum size of the process stack, in bytes. +Upon reaching this limit, a +.B SIGSEGV +signal is generated. +To handle this signal, a process must employ an alternate signal stack +.RB ( sigaltstack (2)). +.IP +Since Linux 2.6.23, +this limit also determines the amount of space used for the process's +command-line arguments and environment variables; for details, see +.BR execve (2). +.SS prlimit() +.\" commit c022a0acad534fd5f5d5f17280f6d4d135e74e81 +.\" Author: Jiri Slaby +.\" Date: Tue May 4 18:03:50 2010 +0200 +.\" +.\" rlimits: implement prlimit64 syscall +.\" +.\" commit 6a1d5e2c85d06da35cdfd93f1a27675bfdc3ad8c +.\" Author: Jiri Slaby +.\" Date: Wed Mar 24 17:06:58 2010 +0100 +.\" +.\" rlimits: add rlimit64 structure +.\" +The Linux-specific +.BR prlimit () +system call combines and extends the functionality of +.BR setrlimit () +and +.BR getrlimit (). +It can be used to both set and get the resource limits of an arbitrary process. +.PP +The +.I resource +argument has the same meaning as for +.BR setrlimit () +and +.BR getrlimit (). +.PP +If the +.I new_limit +argument is not NULL, then the +.I rlimit +structure to which it points is used to set new values for +the soft and hard limits for +.IR resource . +If the +.I old_limit +argument is not NULL, then a successful call to +.BR prlimit () +places the previous soft and hard limits for +.I resource +in the +.I rlimit +structure pointed to by +.IR old_limit . +.PP +The +.I pid +argument specifies the ID of the process on which the call is to operate. +If +.I pid +is 0, then the call applies to the calling process. +To set or get the resources of a process other than itself, +the caller must have the +.B CAP_SYS_RESOURCE +capability in the user namespace of the process +whose resource limits are being changed, or the +real, effective, and saved set user IDs of the target process +must match the real user ID of the caller +.I and +the real, effective, and saved set group IDs of the target process +must match the real group ID of the caller. +.\" FIXME . this permission check is strange +.\" Asked about this on LKML, 7 Nov 2010 +.\" "Inconsistent credential checking in prlimit() syscall" +.SH RETURN VALUE +On success, these system calls return 0. +On error, \-1 is returned, and +.I errno +is set to indicate the error. +.SH ERRORS +.TP +.B EFAULT +A pointer argument points to a location +outside the accessible address space. +.TP +.B EINVAL +The value specified in +.I resource +is not valid; +or, for +.BR setrlimit () +or +.BR prlimit (): +.I rlim\->rlim_cur +was greater than +.IR rlim\->rlim_max . +.TP +.B EPERM +An unprivileged process tried to raise the hard limit; the +.B CAP_SYS_RESOURCE +capability is required to do this. +.TP +.B EPERM +The caller tried to increase the hard +.B RLIMIT_NOFILE +limit above the maximum defined by +.I /proc/sys/fs/nr_open +(see +.BR proc (5)) +.TP +.B EPERM +.RB ( prlimit ()) +The calling process did not have permission to set limits +for the process specified by +.IR pid . +.TP +.B ESRCH +Could not find a process with the ID specified in +.IR pid . +.SH ATTRIBUTES +For an explanation of the terms used in this section, see +.BR attributes (7). +.TS +allbox; +lbx lb lb +l l l. +Interface Attribute Value +T{ +.na +.nh +.BR getrlimit (), +.BR setrlimit (), +.BR prlimit () +T} Thread safety MT-Safe +.TE +.sp 1 +.SH STANDARDS +.TP +.BR getrlimit () +.TQ +.BR setrlimit () +POSIX.1-2008. +.TP +.BR prlimit () +Linux. +.PP +.B RLIMIT_MEMLOCK +and +.B RLIMIT_NPROC +derive from BSD and are not specified in POSIX.1; +they are present on the BSDs and Linux, but on few other implementations. +.B RLIMIT_RSS +derives from BSD and is not specified in POSIX.1; +it is nevertheless present on most implementations. +.BR \%RLIMIT_MSGQUEUE , +.BR RLIMIT_NICE , +.BR RLIMIT_RTPRIO , +.BR RLIMIT_RTTIME , +and +.B \%RLIMIT_SIGPENDING +are Linux-specific. +.SH HISTORY +.TP +.BR getrlimit () +.TQ +.BR setrlimit () +POSIX.1-2001, SVr4, 4.3BSD. +.TP +.BR prlimit () +Linux 2.6.36, +glibc 2.13. +.SH NOTES +A child process created via +.BR fork (2) +inherits its parent's resource limits. +Resource limits are preserved across +.BR execve (2). +.PP +Resource limits are per-process attributes that are shared +by all of the threads in a process. +.PP +Lowering the soft limit for a resource below the process's +current consumption of that resource will succeed +(but will prevent the process from further increasing +its consumption of the resource). +.PP +One can set the resource limits of the shell using the built-in +.I ulimit +command +.RI ( limit +in +.BR csh (1)). +The shell's resource limits are inherited by the processes that +it creates to execute commands. +.PP +Since Linux 2.6.24, the resource limits of any process can be inspected via +.IR /proc/ pid /limits ; +see +.BR proc (5). +.PP +Ancient systems provided a +.BR vlimit () +function with a similar purpose to +.BR setrlimit (). +For backward compatibility, glibc also provides +.BR vlimit (). +All new applications should be written using +.BR setrlimit (). +.SS C library/kernel ABI differences +Since glibc 2.13, the glibc +.BR getrlimit () +and +.BR setrlimit () +wrapper functions no longer invoke the corresponding system calls, +but instead employ +.BR prlimit (), +for the reasons described in BUGS. +.PP +The name of the glibc wrapper function is +.BR prlimit (); +the underlying system call is +.BR prlimit64 (). +.SH BUGS +In older Linux kernels, the +.B SIGXCPU +and +.B SIGKILL +signals delivered when a process encountered the soft and hard +.B RLIMIT_CPU +limits were delivered one (CPU) second later than they should have been. +This was fixed in Linux 2.6.8. +.PP +In Linux 2.6.x kernels before Linux 2.6.17, a +.B RLIMIT_CPU +limit of 0 is wrongly treated as "no limit" (like +.BR 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. +.\" see http://marc.theaimsgroup.com/?l=linux-kernel&m=114008066530167&w=2 +.PP +A kernel bug means that +.\" See https://lwn.net/Articles/145008/ +.B RLIMIT_RTPRIO +does not work in Linux 2.6.12; the problem is fixed in Linux 2.6.13. +.PP +In Linux 2.6.12, there was an off-by-one mismatch +between the priority ranges returned by +.BR getpriority (2) +and +.BR RLIMIT_NICE . +This had the effect that the actual ceiling for the nice value +was calculated as +.IR "19\ \-\ rlim_cur" . +This was fixed in Linux 2.6.13. +.\" see http://marc.theaimsgroup.com/?l=linux-kernel&m=112256338703880&w=2 +.PP +Since Linux 2.6.12, +.\" The relevant patch, sent to LKML, seems to be +.\" http://thread.gmane.org/gmane.linux.kernel/273462 +.\" From: Roland McGrath redhat.com> +.\" Subject: [PATCH 7/7] make RLIMIT_CPU/SIGXCPU per-process +.\" Date: 2005-01-23 23:27:46 GMT +if a process reaches its soft +.B RLIMIT_CPU +limit and has a handler installed for +.BR 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 +.\" Tested Solaris 10, FreeBSD 9, OpenBSD 5.0 +do not change the +.B 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. +.\" FIXME . https://bugzilla.kernel.org/show_bug.cgi?id=50951 +The Linux-specific +.B RLIMIT_RTTIME +limit exhibits the same behavior when the soft limit is encountered. +.PP +Kernels before Linux 2.4.22 did not diagnose the error +.B EINVAL +for +.BR setrlimit () +when +.I rlim\->rlim_cur +was greater than +.IR rlim\->rlim_max . +.\" d3561f78fd379a7110e46c87964ba7aa4120235c +.PP +Linux doesn't return an error when an attempt to set +.B RLIMIT_CPU +has failed, for compatibility reasons. +.\" +.SS Representation of """large""" resource limit values on 32-bit platforms +The glibc +.BR getrlimit () +and +.BR setrlimit () +wrapper functions use a 64-bit +.I rlim_t +data type, even on 32-bit platforms. +However, the +.I rlim_t +data type used in the +.BR getrlimit () +and +.BR setrlimit () +system calls is a (32-bit) +.IR "unsigned long" . +.\" Linux still uses long for limits internally: +.\" c022a0acad534fd5f5d5f17280f6d4d135e74e81 +.\" kernel/sys.c:do_prlimit() still uses struct rlimit which +.\" uses kernel_ulong_t for its members, i.e. 32-bit on 32-bit kernel. +Furthermore, in Linux, +the kernel represents resource limits on 32-bit platforms as +.IR "unsigned long" . +However, a 32-bit data type is not wide enough. +.\" https://bugzilla.kernel.org/show_bug.cgi?id=5042 +.\" https://www.sourceware.org/bugzilla/show_bug.cgi?id=12201 +The most pertinent limit here is +.BR \%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\[em]that is, as wide as a 64-bit +.B off_t +(assuming a program compiled with +.IR _FILE_OFFSET_BITS=64 ). +.PP +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 +.IR "unsigned long" , +then the glibc +.BR setrlimit () +wrapper function silently converted the limit value to +.BR RLIM_INFINITY . +In other words, the requested resource limit setting was silently ignored. +.PP +Since glibc 2.13, +.\" https://www.sourceware.org/bugzilla/show_bug.cgi?id=12201 +glibc works around the limitations of the +.BR \%getrlimit () +and +.BR setrlimit () +system calls by implementing +.BR setrlimit () +and +.BR \%getrlimit () +as wrapper functions that call +.BR prlimit (). +.SH EXAMPLES +The program below demonstrates the use of +.BR prlimit (). +.PP +.\" SRC BEGIN (getrlimit.c) +.EX +#define _GNU_SOURCE +#define _FILE_OFFSET_BITS 64 +#include +#include +#include +#include +#include +#include +\& +int +main(int argc, char *argv[]) +{ + pid_t pid; + struct rlimit old, new; + struct rlimit *newp; +\& + if (!(argc == 2 || argc == 4)) { + fprintf(stderr, "Usage: %s [ " + "]\en", argv[0]); + exit(EXIT_FAILURE); + } +\& + pid = atoi(argv[1]); /* PID of target process */ +\& + newp = NULL; + if (argc == 4) { + new.rlim_cur = atoi(argv[2]); + new.rlim_max = atoi(argv[3]); + newp = &new; + } +\& + /* Set CPU time limit of target process; retrieve and display + previous limit */ +\& + if (prlimit(pid, RLIMIT_CPU, newp, &old) == \-1) + err(EXIT_FAILURE, "prlimit\-1"); + printf("Previous limits: soft=%jd; hard=%jd\en", + (intmax_t) old.rlim_cur, (intmax_t) old.rlim_max); +\& + /* Retrieve and display new CPU time limit */ +\& + if (prlimit(pid, RLIMIT_CPU, NULL, &old) == \-1) + err(EXIT_FAILURE, "prlimit\-2"); + printf("New limits: soft=%jd; hard=%jd\en", + (intmax_t) old.rlim_cur, (intmax_t) old.rlim_max); +\& + exit(EXIT_SUCCESS); +} +.EE +.\" SRC END +.SH SEE ALSO +.BR prlimit (1), +.BR dup (2), +.BR fcntl (2), +.BR fork (2), +.BR getrusage (2), +.BR mlock (2), +.BR mmap (2), +.BR open (2), +.BR quotactl (2), +.BR sbrk (2), +.BR shmctl (2), +.BR malloc (3), +.BR sigqueue (3), +.BR ulimit (3), +.BR core (5), +.BR capabilities (7), +.BR cgroups (7), +.BR credentials (7), +.BR signal (7) -- cgit v1.2.3