LinuxGuruz
  • Last 5 Forum Topics
    Replies
    Views
    Last post


The Web Only This Site
  • BOOKMARK

  • ADD TO FAVORITES

  • REFERENCES


  • MARC

    Mailing list ARChives
    - Search by -
     Subjects
     Authors
     Bodies





    FOLDOC

    Computing Dictionary




  • Text Link Ads






  • LINUX man pages
  • Linux Man Page Viewer


    The following form allows you to view linux man pages.

    Command:

    vlimit

    
    
    

    SYNOPSIS

           #include <sys/time.h>
           #include <sys/resource.h>
    
           int getrlimit(int resource, struct rlimit *rlim);
           int setrlimit(int resource, const struct rlimit *rlim);
    
           int prlimit(pid_t pid, int resource, const struct rlimit *new_limit,
                       struct rlimit *old_limit);
    
       Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
    
           prlimit(): _GNU_SOURCE && _FILE_OFFSET_BITS == 64
    
    
    

    DESCRIPTION

           The  getrlimit() and setrlimit() system calls get and set resource lim-
           its respectively.  Each resource has an associated soft and hard limit,
           as defined by the rlimit structure:
    
               struct rlimit {
                   rlim_t rlim_cur;  /* Soft limit */
                   rlim_t rlim_max;  /* Hard limit (ceiling for rlim_cur) */
               };
    
           The  soft  limit  is  the value that the kernel enforces for the corre-
           sponding 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
           CAP_SYS_RESOURCE capability) may make arbitrary changes to either limit
           value.
    
           The  value  RLIM_INFINITY  denotes  no limit on a resource (both in the
           structure returned by getrlimit() and in the structure passed to  setr-
           limit()).
    
           The resource argument must be one of:
    
           RLIMIT_AS
                  The maximum size of the process's virtual memory (address space)
                  in bytes.  This limit  affects  calls  to  brk(2),  mmap(2)  and
                  mremap(2),  which fail with the error ENOMEM upon exceeding this
                  limit.  Also automatic stack expansion will fail (and generate a
                  SIGSEGV  that  kills  the process if no alternate stack has been
                  made available via sigaltstack(2)).  Since the value is a  long,
                  on  machines  with  a 32-bit long either this limit is at most 2
                  GiB, or this resource is unlimited.
    
           RLIMIT_CORE
                  Maximum size of core file.  When 0 no core dump files  are  cre-
                  ated.  When nonzero, larger dumps are truncated to this size.
    
           RLIMIT_DATA
                  The maximum size of  the  process's  data  segment  (initialized
                  data,  uninitialized  data, and heap).  This limit affects calls
                  to brk(2) and sbrk(2), which fail with  the  error  ENOMEM  upon
                  encountering the soft limit of this resource.
    
           RLIMIT_FSIZE
                  The maximum size of files that the process may create.  Attempts
                  to extend a file beyond this  limit  result  in  delivery  of  a
                  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., write(2), truncate(2)) fails with
                  the error EFBIG.
    
           RLIMIT_LOCKS (Early Linux 2.4 only)
                  A limit on the combined number of flock(2)  locks  and  fcntl(2)
                  leases that this process may establish.
    
           RLIMIT_MEMLOCK
                  The  maximum  number  of bytes of memory that may be locked into
                  RAM.  In effect this limit is rounded down to the nearest multi-
                  ple  of  the  system page size.  This limit affects mlock(2) and
                  mlockall(2) and the mmap(2) MAP_LOCKED operation.   Since  Linux
                  2.6.9 it also affects the shmctl(2) SHM_LOCK operation, where it
                  sets a maximum on the total bytes in shared memory segments (see
                  shmget(2)) that may be locked by the real user ID of the calling
                  process.  The shmctl(2) SHM_LOCK locks are accounted  for  sepa-
                  rately   from   the  per-process  memory  locks  established  by
                  mlock(2), mlockall(2), and mmap(2)  MAP_LOCKED;  a  process  can
                  lock bytes up to this limit in each of these two categories.  In
                  Linux kernels before 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.
    
           RLIMIT_MSGQUEUE (since Linux 2.6.8)
                  Specifies the 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 mq_open(3).   Each  message
                  queue that the user creates counts (until it is removed) against
                  this limit according to the formula:
    
                      bytes = attr.mq_maxmsg * sizeof(struct msg_msg *) +
                              attr.mq_maxmsg * attr.mq_msgsize
    
                  where attr is the mq_attr  structure  specified  as  the  fourth
                  argument to mq_open(3).
    
                  The  first  addend  in the formula, which includes sizeof(struct
                  msg_msg *) (4 bytes on Linux/i386), ensures that the user cannot
                  create  an  unlimited  number of zero-length messages (such mes-
                  number that can be opened by this process.   Attempts  (open(2),
                  pipe(2),  dup(2),  etc.)   to  exceed this limit yield the error
                  EMFILE.  (Historically, this limit  was  named  RLIMIT_OFILE  on
                  BSD.)
    
           RLIMIT_NPROC
                  The  maximum  number  of processes (or, more precisely on Linux,
                  threads) that can be created for the real user ID of the calling
                  process.   Upon  encountering this limit, fork(2) fails with the
                  error EAGAIN.
    
           RLIMIT_RSS
                  Specifies the limit (in pages) of  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 madvise(2) specifying MADV_WILLNEED.
    
           RLIMIT_RTPRIO (since Linux 2.6.12, but see BUGS)
                  Specifies  a  ceiling  on the real-time priority that may be set
                  for this  process  using  sched_setscheduler(2)  and  sched_set-
                  param(2).
    
           RLIMIT_RTTIME (since Linux 2.6.25)
                  Specifies  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
                  sched_yield(2).
    
                  Upon reaching the soft limit, the process is sent a SIGXCPU sig-
                  nal.   If the process catches or ignores this signal and contin-
                  ues consuming CPU time, then SIGXCPU will be generated once each
                  second  until the hard limit is reached, at which point the pro-
                  cess is sent a SIGKILL signal.
    
                  The intended use of this limit is to stop  a  runaway  real-time
                  process from locking up the system.
    
           RLIMIT_SIGPENDING (since Linux 2.6.8)
                  Specifies  the 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 sigqueue(3);  it
                  is  always  possible to use kill(2) to queue one instance of any
                  of the signals that are not already queued to the process.
    
           RLIMIT_STACK
                  The maximum size of the process stack, in bytes.  Upon  reaching
                  this  limit, a SIGSEGV signal is generated.  To handle this sig-
    
           If the new_limit argument is a not NULL, then the rlimit  structure  to
           which  it points is used to set new values for the soft and hard limits
           for resource.  If the old_limit argument is a not NULL, then a success-
           ful  call  to  prlimit()  places  the previous soft and hard limits for
           resource in the rlimit structure pointed to by old_limit.
    
           The pid argument specifies the ID of the process on which the  call  is
           to operate.  If 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 CAP_SYS_RESOURCE capability, or the real, effective, and
           saved set user IDs of the target process must match the real user ID of
           the caller and the real, effective, and saved set group IDs of the tar-
           get process must match the real group ID of the caller.
    
    
    

    RETURN VALUE

           On success, these system calls return 0.  On error, -1 is returned, and
           errno is set appropriately.
    
    
    

    ERRORS

           EFAULT A  pointer  argument points to a location outside the accessible
                  address space.
    
           EINVAL The value specified in resource is  not  valid;  or,  for  setr-
                  limit()   or   prlimit():   rlim->rlim_cur   was   greater  than
                  rlim->rlim_max.
    
           EPERM  An unprivileged process tried  to  raise  the  hard  limit;  the
                  CAP_SYS_RESOURCE  capability  is  required  to do this.  Or, the
                  caller tried to increase the hard RLIMIT_NOFILE limit above  the
                  current  kernel  maximum (NR_OPEN).  Or, the calling process did
                  not have permission to set limits for the process  specified  by
                  pid.
    
           ESRCH  Could not find a process with the ID specified in pid.
    
    
    

    VERSIONS

           The  prlimit()  system  call  is available since Linux 2.6.36.  Library
           support is available since glibc 2.13.
    
    
    

    CONFORMING TO

           getrlimit(), setrlimit(): SVr4, 4.3BSD, POSIX.1-2001.
           prlimit(): Linux-specific.
    
           RLIMIT_MEMLOCK and RLIMIT_NPROC derive from BSD and are  not  specified
           in  POSIX.1-2001;  they  are  present on the BSDs and Linux, but on few
           other implementations.  RLIMIT_RSS derives from BSD and is  not  speci-
           fied  in  POSIX.1-2001;  it is nevertheless present on most implementa-
           tions.  RLIMIT_MSGQUEUE, RLIMIT_NICE, RLIMIT_RTPRIO, RLIMIT_RTTIME, and
           RLIMIT_SIGPENDING are Linux-specific.
    
    
    

    NOTES

           Ancient  systems provided a vlimit() function with a similar purpose to
           setrlimit().  For backward compatibility, glibc also provides vlimit().
           All new applications should be written using setrlimit().
    
    
    

    BUGS

           In  older Linux kernels, the SIGXCPU and SIGKILL signals delivered when
           a process encountered the soft and hard RLIMIT_CPU limits  were  deliv-
           ered 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, set-
           ting 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.
    
    
    

    EXAMPLE

           The program below demonstrates the use of prlimit().
    
           #define _GNU_SOURCE
           #define _FILE_OFFSET_BITS 64
           #include <stdio.h>
           #include <time.h>
           #include <stdlib.h>
           #include <unistd.h>
           #include <sys/resource.h>
    
           #define errExit(msg)     do { perror(msg); exit(EXIT_FAILURE); \
                                   } while (0)
    
           int
               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)
                   errExit("prlimit-1");
               printf("Previous limits: soft=%lld; hard=%lld\n",
                       (long long) old.rlim_cur, (long long) old.rlim_max);
    
               /* Retrieve and display new CPU time limit */
    
               if (prlimit(pid, RLIMIT_CPU, NULL, &old) == -1)
                   errExit("prlimit-2");
               printf("New limits: soft=%lld; hard=%lld\n",
                       (long long) old.rlim_cur, (long long) old.rlim_max);
    
               exit(EXIT_FAILURE);
           }
    
    
    

    SEE ALSO

           prlimit(1), dup(2), fcntl(2), fork(2), getrusage(2), mlock(2), mmap(2),
           open(2),  quotactl(2),  sbrk(2),  shmctl(2),  malloc(3),   sigqueue(3),
           ulimit(3), core(5), capabilities(7), signal(7)
    
    
    

    Linux 2014-01-22 GETRLIMIT(2)

    
    
  • MORE RESOURCE


  • Linux

    The Distributions





    Linux

    The Software





    Linux

    The News



  • MARKETING






  • Toll Free

webmaster@linuxguruz.com
Copyright © 1999 - 2016 by LinuxGuruz