getrlimit() - Unix、Linux 系統呼叫 - 技術教學

Unix 初學者指南

Unix Shell 程式設計

高階 Unix

Unix 有用參考

Unix 有用資源

精選閱讀

首頁

參考

討論論壇

關於 TP

getrlimit() - Unix、Linux 系統呼叫

名稱

getrlimit、setrlimit - 獲取/設定資源限制

語法

#include <sys/time.h>
#include <sys/resource.h>

int getrlimit(int resource, struct rlimit *rlim);
int setrlimit(int resource, const struct rlimit *rlim);

描述

getrlimit() 和 setrlimit() 分別獲取和設定資源限制。每個資源都有一個關聯的軟限制和硬限制，如 rlimit 結構（getrlimit() 和 setrlimit() 的 rlim 引數）中所定義。

struct rlimit {
    rlim_t rlim_cur;  /* Soft limit */
    rlim_t rlim_max;  /* Hard limit (ceiling for rlim_cur) */
};

軟限制是核心對相應資源執行的值。硬限制充當軟限制的上限：非特權程序只能將其軟限制設定為從 0 到硬限制範圍內的值，並且（不可逆地）降低其硬限制。特權程序（在 Linux 中：具有 CAP_SYS_RESOURCE 能力的程序）可以對任一限制值進行任意更改。

值 RLIM_INFINITY 表示對資源沒有限制（在 getrlimit() 返回的結構中以及傳遞給 setrlimit() 的結構中）。

resource 必須是以下之一：

標籤

描述

RLIMIT_AS

程序虛擬記憶體（地址空間）的最大大小（以位元組為單位）。此限制會影響對 brk(2)、mmap(2) 和 mremap(2) 的呼叫，這些呼叫在超出此限制時會失敗並出現 ENOMEM 錯誤。此外，自動堆疊擴充套件也會失敗（如果未透過 sigaltstack(2) 提供備用堆疊，則會生成一個終止程序的 SIGSEGV）。由於該值是 long 型別，因此在具有 32 位 long 的機器上，此限制最多為 2 GiB，或者此資源是無限的。

RLIMIT_CORE

core 檔案的最大大小。當為 0 時，不建立 core dump 檔案。當不為零時，較大的 dump 將被截斷到此大小。

RLIMIT_CPU

CPU 時間限制（以秒為單位）。當程序達到軟限制時，會向其傳送 SIGXCPU 訊號。此訊號的預設操作是終止程序。但是，可以捕獲該訊號，並且處理程式可以將控制權返回到主程式。如果程序繼續消耗 CPU 時間，則每秒鐘會向其傳送一次 SIGXCPU，直到達到硬限制，此時會向其傳送 SIGKILL。（後一點描述了 Linux 2.2 到 2.6 的行為。實現方式在處理達到軟限制後繼續消耗 CPU 時間的程序方面有所不同。需要捕獲此訊號的可移植應用程式應在首次收到 SIGXCPU 時執行有序終止）。

RLIMIT_DATA

程序資料段（已初始化資料、未初始化資料和堆）的最大大小。此限制會影響對 brk() 和 sbrk() 的呼叫，這些呼叫在遇到此資源的軟限制時會失敗並出現 ENOMEM 錯誤。

RLIMIT_FSIZE

程序可以建立的檔案的最大大小。嘗試將檔案擴充套件到此限制之外會導致傳送 SIGXFSZ 訊號。預設情況下，此訊號會終止程序，但程序可以改為捕獲此訊號，在這種情況下，相關的系統呼叫（例如，write() truncate()）會失敗並出現 EFBIG 錯誤。

RLIMIT_LOCKS（僅限早期 Linux 2.4）

對該程序可以建立的 flock() 鎖和 fcntl() 租約的總數的限制。

RLIMIT_MEMLOCK

可以鎖定到 RAM 的記憶體位元組的最大數量。實際上，此限制會向下舍入到最接近的系統頁面大小的倍數。此限制會影響 mlock(2) 和 mlockall(2) 以及 mmap(2) MAP_LOCKED 操作。從 Linux 2.6.9 開始，它還會影響 shmctl(2) SHM_LOCK 操作，其中它為呼叫程序的真實使用者 ID 可以鎖定的共享記憶體段（請參閱 shmget(2)）中的總位元組數設定最大值。shmctl(2) SHM_LOCK 鎖與 mlock(2)、mlockall(2) 和 mmap(2) MAP_LOCKED 建立的每個程序的記憶體鎖分開計算；程序可以在這兩個類別中的每個類別中鎖定此限制範圍內的位元組數。在 2.6.9 之前的 Linux 核心中，此限制控制特權程序可以鎖定的記憶體量。從 Linux 2.6.9 開始，對特權程序可以鎖定的記憶體量沒有限制，而此限制則控制非特權程序可以鎖定的記憶體量。

RLIMIT_MSGQUEUE（自 Linux 2.6.8 起）

指定可以為呼叫程序的真實使用者 ID 分配的 POSIX 訊息佇列的位元組數限制。此限制對 mq_open(3) 強制執行。使用者建立的每個訊息佇列（直到將其刪除）都會根據以下公式對此限制進行計算：


    bytes = attr.mq_maxmsg * sizeof(struct msg_msg *) +
            attr.mq_maxmsg * attr.mq_msgsize

其中 attr 是作為 mq_open() 的第四個引數指定的 mq_attr 結構。

公式中的第一個加數（包括 sizeof(struct msg_msg *)（在 Linux/x86 上為 4 位元組））確保使用者不能建立無限數量的零長度訊息（儘管如此，這些訊息仍然會消耗一些系統記憶體用於簿記開銷）。

RLIMIT_NICE（自核心 2.6.12 起，但請參閱下面的 BUG）

指定可以使用 setpriority(2) 或 nice(2) 將程序的 nice 值提高到的上限。nice 值的實際上限計算為 20 - rlim_cur。（這種奇怪的情況發生是因為負數不能指定為資源限制值，因為它們通常具有特殊含義。例如，RLIM_INFINITY 通常與 -1 相同）。

RLIMIT_NOFILE

指定一個值，該值比此程序可以開啟的檔案描述符號的最大值大 1。嘗試（open()、pipe()、dup() 等）超過此限制會導致 EMFILE 錯誤。

RLIMIT_NPROC

可以為呼叫程序的真實使用者 ID 建立的執行緒的最大數量。遇到此限制時，fork() 會失敗並出現 EAGAIN 錯誤。

RLIMIT_RSS

指定程序駐留集（駐留在 RAM 中的虛擬頁數）的限制（以頁為單位）。此限制僅在 Linux 2.4.x（x < 30）中有效，並且僅影響指定 MADV_WILLNEED 的 madvise() 呼叫。

RLIMIT_RTPRIO（自 Linux 2.6.12 起，但請參閱 BUG）

指定可以使用 sched_setscheduler(2) 和 sched_setparam(2) 為此程序設定的即時優先順序的上限。

RLIMIT_SIGPENDING（自 Linux 2.6.8 起）

指定可以為呼叫程序的真實使用者 ID 排隊的訊號數限制。標準訊號和即時訊號都計入檢查此限制的目的。但是，此限制僅對 sigqueue(2) 強制執行；始終可以使用 kill(2) 來排隊任何尚未排隊到程序的訊號的一個例項。

RLIMIT_STACK

程序堆疊的最大大小（以位元組為單位）。達到此限制時，會生成 SIGSEGV 訊號。要處理此訊號，程序必須使用備用訊號堆疊（sigaltstack(2)）。

RLIMIT_OFILE 是 RLIMIT_NOFILE 的 BSD 名稱。

返回值

成功時，返回 0。錯誤時，返回 -1，並且 errno 設定為相應的值。

錯誤

標籤	描述
EFAULT	rlim 指向可訪問地址空間之外。
EINVAL	resource 無效；或者，對於 setrlimit()：rlim->rlim_cur 大於 rlim->rlim_max。
EPERM	非特權程序嘗試使用 setrlimit() 將軟限制或硬限制提高到當前硬限制之上；需要 CAP_SYS_RESOURCE 能力才能執行此操作。或者，程序嘗試使用 setrlimit() 將軟限制或硬限制 RLIMIT_NOFILE 限制提高到當前核心最大值 (NR_OPEN) 以上。

BUG

在較舊的 Linux 核心中，當程序遇到軟限制和硬限制 RLIMIT_CPU 限制時傳送的 SIGXCPU 和 SIGKILL 訊號比應有的時間晚了一 (CPU) 秒。此問題已在核心 2.6.8 中修復。

在 2.6.x 核心（2.6.17 之前）中，0 的 RLIMIT_CPU 限制被錯誤地視為“無限制”（如 RLIM_INFINITY）。從核心 2.6.17 開始，設定 0 的限制確實會產生影響，但實際上被視為 1 秒的限制。

核心錯誤意味著 RLIMIT_RTPRIO 在核心 2.6.12 中不起作用；此問題已在核心 2.6.13 中修復。

在核心 2.6.12 中，getpriority(2) 和 RLIMIT_NICE 返回的優先順序範圍之間存在一個差 1 的不匹配。這導致 nice 值的實際上限計算為 19 - rlim_cur。此問題已在核心 2.6.13 中修復。

2.4.22 之前的核心未診斷 setrlimit() 的 EINVAL 錯誤，當時 rlim->rlim_cur 大於 rlim->rlim_max。

註釋

透過 fork(2) 建立的子程序繼承其父程序的資源限制。資源限制在 execve(2) 中得以保留。

符合標準

SVr4、4.3BSD、POSIX.1-2001。RLIMIT_MEMLOCK 和 RLIMIT_NPROC 源自 BSD，並且未在 POSIX.1-2001 中指定；它們存在於 BSD 和 Linux 上，但在其他一些實現中卻很少見。RLIMIT_RSS 源自 BSD，並且未在 POSIX.1-2001 中指定；儘管如此，它仍然存在於大多數實現中。RLIMIT_MSGQUEUE、RLIMIT_NICE、RLIMIT_RTPRIO 和 RLIMIT_SIGPENDING 是 Linux 特定的。

參見

列印頁面