Chapter 1. Process Limits

Standard system resource limits are applied so that each login process receives the same process-based limits at the time the process is created. This chapter describes process limits and contains the following sections:

Process Limits Overview

The IRIX operating system supports limits on individual processes. Limits on the consumption of a variety of system resources by a process and each process it creates may be obtained with the getrlimit(2) system call and set with the setrlimit(2) system call.

Each call to either getrlimit or setrlimit identifies a specific resource to be operated upon as well as a resource limit. A resource limit is a pair of values: one specifying the current (soft) limit, the other a maximum (hard) limit. Soft limits may be changed by a process to any value that is less than or equal to the hard limit. A process may (irreversibly) lower its hard limit to any value that is greater than or equal to the soft limit.

Using csh and sh to Limit Resource Consumption

The csh or sh limit -h resource max-use commands can be used to limit the resource consumption by the current process or any process it spawns.

These commands limit the consumption by the current process and each process it creates to not individually exceed maximum-use on the specified resource. If no maximum-use is given, then the current limit is printed; if no resource is given, then all limitations are given. If the -h flag is given, the hard (maximum) limits are used instead of the current limits. The hard limits impose a ceiling on the values of the current limits. To raise maximum (hard) limits, you must have the CAP_PROC_MGT capability.

For additional information, see the csh(1) and sh(1) man pages. For more information on the capability mechanism that provides fine grained control over the privileges of a process, see the capability(4) and capabilities(4) man pages.

Using systune to Display and Set Process Limits

Table 1-1 shows the process limits supported by the IRIX operating system.

Table 1-1. Process Limits

Limit Name

Symbolic ID

Units

Description

Enforcement

rlimit_cpu_cur
rlimit_cpu_max

RLIMIT_CPU

seconds

Maximum number of CPU seconds the process is allowed

Process termination via SIGXCPU signal

rlimit_fsize_cur
rlimit_fsize_max

RLIMIT_FSIZE

bytes

Maximum size of file that can be created by process

Write/expansion attempt fails with errno set to EFBIG

rlimit_data_cur
rlimit_data_max

RLIMIT_DATA

bytes

Maximum process heap size

brk(2) calls fail with errno set to ENOMEM

rlimit_stack_cur
rlimit_stack_max

RLIMIT_STACK

bytes

Maximum process stack size

Process termination via SIGSEGV signal

rlimit_ core_cur
rlimit_core_max

RLIMIT_CORE

bytes

Maximum size of a core file that can be created by process

Writing of core file terminated at limit

rlimit_nofile_cur
rlimit_nofile_max

RLIMIT_NOFILE

file descriptors

Maximum number of open file descriptors process can have

open(2) attempts file with errno set to EMFILE

rlimit_vmem_cur
rlimit_vmem_max

RLIMIT_VMEM

bytes

Maximum process address space

brk(2) and mmap(2) calls fail with errno set to ENOMEM

rlimit_rss_cur
rlimit_rss_max

RLIMIT_RSS

bytes

Maximum size of resident set size of the process

Resident pages above limit become prime swap candidates

rlimit_pthread_cur
rlimit_pthread_max

RLIMIT_PTHREAD

threads

Maximum number of threads that process can create

Thread creation fails with errno set to EAGAIN


You can use the systune resource command to view and set systemwide default values for process limits. The resource group contains the following variables:

rlimit_cpu_cur
rlimit_cpu_max
rlimit_fsize_cur
rlimit_fsize_max
rlimit_data_cur
rlimit_data_max
rlimit_stack_cur
rlimit_stack_max
rlimit_core_cur
rlimit_core_max
rlimit_nofile_cur
rlimit_nofile_max
rlimit_vmem_cur
rlimit_vmem_max
rlimit_rss_cur
rlimit_rss_max
rlimit_pthread_cur
rlimit_pthread_max

For additional information, see the systune(1M) man page.

If job limits software is installed and running on the system, you can choose to set user-based process limits values in the user limits database (ULDB). Both current and maximum values, such as rlimit_cpu_cur and rlimit_cpu_max can be specified. Values in the ULDB override the system defaults set by the systune(1M) command.

For additional information on the ULDB, see “User Limits Database” in Chapter 2.

Additional Process Limits Parameters

IRIX has configurable parameters for certain system limits. For example, you can set maximum values for each process (its core or file size), the number of groups per user, the number of resident pages, and so forth. The maxup and cpulimit_gracetime are described below. All parameters are set and defined in /var/sysgen/mtune.

maxup 

Maximum number of processes per user

cpulimit_gracetime 

Process and job limit grace period

For additional information on the maxup parameter and other “System Limits Parameters”, see IRIX Admin: System Configuration and Operation.

The cpulimit_gracetime parameter establishes a grace period for processes that exceed the CPU time limit. You should set it to the number of seconds that a process will be allowed to run after exceeding the limit. When cputlimit_gracetime is not set (that is, when it is zero), any process that exceeds either the process or job CPU limit will be sent a SIGXCPU signal. The kernel will periodically send a SIGXCPU signal to that process as long as it continues to execute. Since a process can register to handle a SIGXCPU signal, the process can effectively ignore the CPU limit.

If you use the systune(1M) command to set the cpulimit_gracetime parameter to a nonzero value, its behavior changes. When a process exceeds the CPU limit, the kernel sends a SIGXCPU signal to a process only once. The process can register for this signal and then perform any cleanup and shutdown operations it wants to perform. If the process is still running after accruing cpulimit_gracetime more seconds of CPU time, the kernel terminates the process with a SIGKILL signal.