リナックスコマンド

getrlimitのヘルプ・マニュアル

日本語 英語

• help
• man

getrlimit --help

man getrlimit

GETRLIMIT(2) Linux Programmer’s Manual GETRLIMIT(2) 名前 getrlimit, setrlimit - 資源の制限を取得/設定する 書式 #include #include int getrlimit(int resource, struct rlimit *rlim); int setrlimit(int resource, const struct rlimit *rlim); 説明 getrlimit() と setrlimit() はそれぞれ資源 (resource) の制限 (limit) の 設定と取得を行う。各リソースには、それに対応するソフト・リミットとハ ー ド・リミットがある。リミットは (getrlimit() と setrlimit() の rlim 引き 数である) rlimit 構造体で定義される: struct rlimit { rlim_t rlim_cur; /* ソフト・リミット */ rlim_t rlim_max; /* ハード・リミット (rlim_cur より小さくない) */ }; ソフト・リミットは、カーネルが対応するリソースに対して課す制限値であ る 。 ハード・リミットはソフト・リミットの上限として働く。特権を持たないプ ロセスは、ソフト・リミットの値を 0 からハード・リミットの範囲に設定する こ とと、ハード・リミットを下げることのみができる (一度下げたハードリミ ットは上げられない)。特権プロセス (Linux では CAP_SYS_RESOURCE ケーパビ リ ティ (capability) を持つプロセス) はソフト・リミットとハード・リミッ トを自由に変更できる。 値 RLIM_INFINITY はリソースに制限がないことを表す (この値は getrlimit() が返す構造体と setrlimit() に渡す構造体の両方で使用される)。 resource は次のいずれか 1 つである。 RLIMIT_AS プ ロセスの仮想メモリ (アドレス空間) の最大サイズ (バイト単位)。 この制限は brk(2), mmap(2), mremap(2) の呼び出しに影響し、この制 限を超えた場合はエラー ENOMEM で失敗する。また自動的なスタック拡 張にも失敗する (さらに sigaltstack(2) を使った代替スタックを利用 可 能にしていなかった場合には、 SIGSEGV を生成してそのプロセスを kill する)。この値は long 型なので、32 ビットの long 型を持つ マ シ ンでは、この制限は最大で 2 GiB になるか、この資源が無制限にな る。 RLIMIT_CORE core ファイルの最大サイズ。 0 の場合、core ファイルは生成され な い。 0 以外の場合、このサイズより大きいダンプは切り詰められる。 RLIMIT_CPU CPU 時間の上限 (秒数)。プロセスがソフト・リミットに達した場合に 、 SIGXCPU シグナルを送る。このシグナルに対するデフォルトの動 作 は、プロセスの終了である。ただしシグナルをキャッチして、ハンドラ がメインプログラムに制御を返すこともできる。プロセスが CPU 時 間 を 使い続けた場合は、ハードリミットに達するまで 1 秒毎にプロセス に SIGXCPU を送り、ハードリミットに達すると SIGKILL を送る。ソフ ト・リミットを超過したときの動作は、 Linux 2.2 から 2.6 のもので ある。ソフト・リミットを超えて CPU 時間を使い続けるプロセスの 扱 い方についての実装は変化してきている。このシグナルをキャッチする 必要のある移植性を考えたアプリケーションでは、最初に SIGXCPU を 受け取った時点で正しく終了すべきである。 RLIMIT_DATA プロセスのデータセグメント (初期化されたデータ・初期化されていな いデータ・ヒープ) の最大値。このリミットは brk(2) と sbrk(2) の 呼び出しに影響する。これらの関数は、このリソースのソフト・リミッ トに達すると、エラー ENOMEM で失敗する。 RLIMIT_FSIZE プロセスが作成できるファイルサイズの最大値。このサイズを超えてフ ァ イルを拡張すると、 SIGXFSZ シグナルを送る。デフォルトでは、こ のシグナルはプロセスを終了する。プロセスをキャッチすることもでき るが、関連するシステムコール (write(2), truncate(2) など) はエラ ー EFBIG で失敗する。 RLIMIT_LOCKS (初期の Linux 2.4 のみ) このプロセスが実行できる flock(2) ロック数と fcntl(2) リース数の 合計値を制限する。 RLIMIT_MEMLOCK RAM 内にロックできるメモリの最大バイト数。実際には、この制限はシ ステムページサイズの最も近い倍数に切り捨てて丸められる。この制限 は mlock(2), mlockall(2), mmap(2) の MAP_LOCKED 操作に影響する。 Linux 2.6.9 以降では shmctl(2) SHM_LOCK 操作にも影響する。この操 作は呼び出し元プロセスの実 (real) ユーザー ID にロックされる共有 メモリセグメント (shmget(2) を参照) の合計バイト数の最大値を設定 す る 。 shmctl(2) SHM_LOCK によるロックは、 mlock(2), mlock- all(2), mmap(2) の MAP_LOCKED によって確立されるプロセス毎のメモ リ ロックとは分けて数える。 1 つのプロセスはこの制限までのバイト をロックできる。この制限には 2 つの種類がある。 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_attr 構造体であり、 mq_open(3) の第 4 引き数と して指定される。 sizeof(struct msg_msg *) (Linux/i386 では 4 バイト) を含む最初の 加数は、ユーザーが長さ 0 のメッセージを無制限に作れないこと保 証 している (このようなメッセージであっても、記録のためのオーバーヘ ッドでシステムメモリを消費する)。 RLIMIT_NICE (Linux 2.6.12 以降, 下記の「バグ」の節も参照) setpriority(2) や nice(2) を使って引き上げられるプロセスの nice 値 の上限を指定する。 nice 値の実際の上限は 20 - rlim_cur で計算 される (このような変な状況は、リソース制限値として負の数を指定で きないため発生する。通常、負の値は特別な意味を持っているからであ る。例えば、通常は RLIM_INFINITY の値は -1 である)。 RLIMIT_NOFILE このプロセスがオープンできるファイルディスクリプタ数の最大値より 1 大きい値を指定する。 (open(2), pipe(2), dup(2) などにより) こ の上限を超えようとした場合、エラー EMFILE が発生する (歴史 的 に 、BSD ではこの上限は RLIMIT_OFILE という名前となっている)。 RLIMIT_NPROC 呼び出したプロセスの実ユーザー ID で作成できる最大プロセス数 (よ り正確には Linux ではスレッド数)。この上限に達すると 、 fork(2) はエラー EAGAIN で失敗する。 RLIMIT_RSS プ ロセスの resident set (RAM 上に存在する仮想ページの数) の上限 を (ページ数で) 指定する。この制限は 2.4.30 より前でしか影響がな く 、 madvise(2) に MADV_WILLNEED を指定した関数コールにしか影響 しない。 RLIMIT_RTPRIO (Linux 2.6.12 以降, バグの節も参照) sched_setscheduler(2) や sched_setparam(2) を使って設定できる 、 そのプロセスのリアルタイム優先度の上限を指定する。 RLIMIT_RTTIME (Linux 2.6.25 以降) リアルタイム・スケジューリング方針でスケジューリングされるプロセ スがブロッキング型のシステムコールを呼び出さずに消費することので き る CPU 時間の合計についての上限を指定する。この上限の目的のた め、プロセスがブロッキング型のシステムコールを呼び出す度に、消費 さ れ た CPU 時間のカウントは 0 にリセットされる。プロセスが CPU を使い続けようとしたが他のプロセスに置き換えられ た (preempted) 場合や、そのプロセスのタイムスライスが満了した場合、そのプロセス が sched_yield(2) を呼び出した場合は、CPU 時間のカウントはリセッ トされない。 ソ フト・リミットに達すると、そのプロセスに SIGXCPU シグナルが送 られる。そのプロセスがこのシグナルを捕捉するか無視して、CPU 時間 を消費し続けた場合には、ハード・リミットに達するまで 1 秒に 1 回 SIGXCPU が生成され続けることになる。ハード・リミットに達した時点 で、そのプロセスには SIGKILL シグナルが送られる。 この上限を意図的に使用するのは、暴走したリアルタイム・プロセスを 停止して、システムが動かなくなるのを避ける場合である。 RLIMIT_SIGPENDING (Linux 2.6.8 以降) 呼び出し元プロセスの実ユーザー ID に対してキューに入れられるシグ ナルの数の制限を指定する。この制限をチェックするため、標準シグナ ルとリアルタイム・シグナルの両方がカウントされる。しかし、この制 限は sigqueue(2) に対してしか強制されず、 kill(2) 使うことで、そ のプロセスに対してまだキューに入れられていないシグナルのインスタ ンスをキューに入れることができる。 RLIMIT_STACK プロセス・スタックの最大サイズをバイト単位で指定する。この上限に 達すると、 SIGSEGV シグナルが生成される。このシグナルを扱うた め には、プロセスは代りのシグナルスタック (sigaltstack(2)) を使用し なければならない。 Linux 2.6.23 以降では、この制限はプロセスのコマンドライン引き 数 と環境変数に使用される空間の合計サイズの上限の決定にも使用される 。詳細については execve(2) を参照。 返り値 成功した場合は 0 が返される。エラーの場合は -1 が返され、 errno に適 切 な値が設定される。 エラー EFAULT rlim がアクセス可能なアドレス空間の外を指している。 EINVAL resource が有効でない。または、 setrlimit() で、 rlim->rlim_cur が rlim->rlim_max よりも大きかった。 EPERM 特権のないプロセスが setrlimit() を使用してソフト・リミットま た はハード・リミットを現在のハード・リミットより大きくしようと試み た。これを行うためには CAP_SYS_RESOURCE ケーパビリティが必要であ る 。または特権のないプロセスが setrlimit() を使用してソフトまた はハード RLIMIT_NOFILE リミットを現在 の カ ー ネ ル の 最 大 値 (NR_OPEN) 以上に増加させようとした。 準拠 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_RTTIME, RLIMIT_SIG- PENDING は Linux 固有のものである。 注意 fork(2) で作成された作成された子プロセスは、親プロセスのリソース制限 を 継承する。 execve(2) の前後でリソース制限は保存される。 シ ェ ルのリソース制限は、シェルの組み込みコマンドである ulimit (csh(1) では limit ) を使って設定することができる。このシェルのリソース制限は、 コマンドを実行してシェルが生成するプロセスに引き継がれる。 バグ 以前の Linux カーネルでは、プロセスがソフトまたはハード RLIMIT_CPU リミ ットに達した場合に送られる SIGXCPU と SIGKILL シグナルが、本来送られ る べ き時点の 1 (CPU) 秒後に送られてしまう。これはカーネル 2.6.8 で修正さ れた。 2.6.17 より前の 2.6.x カーネルでは、 RLIMIT_CPU リミットが 0 の場 合 、 (RLIM_INFINITY と 同 じように) 「制限なし」と間違って解釈されていた。 Linux 2.6.17 以降では、リミットを 0 に設定した場合にも効果を持つよう に なっているが、実際にはリミットの値は 1 秒となる。 カーネル 2.6.12 には、 RLIMIT_RTPRIO が動作しないというバグがある。この 問題はカーネル 2.6.13 で修正されている。 カーネル 2.6.12 では、 getpriority(2) と RLIMIT_NICE が返す優先度の範囲 が 一つずれていた。このため、nice 値の実際の上限が 19 - rlim_cur になっ てしまうという影響があった。これはカーネル 2.6.13 で修正された。 2.4.22 より前のカーネルでは、 rlim->rlim_cur が rlim->rlim_max より大き かった場合、 setrlimit() での EINVAL エラーを検出できない。 関連項目 dup(2), fcntl(2), fork(2), getrusage(2), mlock(2), mmap(2), open(2), quotactl(2), sbrk(2), shmctl(2), sigqueue(2), malloc(3), ulimit(3), core(5), capabilities(7), signal(7) Linux 2008-10-06 GETRLIMIT(2)

GETRLIMIT(2) Linux Programmer’s Manual GETRLIMIT(2) NAME getrlimit, setrlimit - get/set resource limits SYNOPSIS #include #include int getrlimit(int resource, struct rlimit *rlim); int setrlimit(int resource, const struct rlimit *rlim); DESCRIPTION getrlimit() and setrlimit() get and set resource limits respectively. Each resource has an associated soft and hard limit, as defined by the rlimit structure (the rlim argument to both getrlimit() and setr- limit()): 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 only set 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()). resource 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 non-zero, larger dumps are truncated to this size. RLIMIT_CPU CPU time limit in seconds. When the process reaches the soft limit, it is sent a 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 SIGXCPU once per second until the hard limit is reached, at which time it is sent SIGKILL. (This latter point describes Linux 2.2 through 2.6 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 SIGXCPU.) 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- sages nevertheless each consume some system memory for bookkeep- ing overhead). RLIMIT_NICE (since Linux 2.6.12, but see BUGS below) Specifies a ceiling to which the process’s nice value can be raised using setpriority(2) or nice(2). The actual ceiling for the nice value is calculated as 20 - rlim_cur. (This strangeness occurs because negative numbers cannot be specified as resource limit values, since they typically have special meanings. For example, RLIM_INFINITY typically is the same as -1.) RLIMIT_NOFILE Specifies a value one greater than the maximum file descriptor 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 only has effect in Linux 2.4.x, x < 30, and there only affects 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 on the amount of CPU time that a process scheduled under a real-time scheduling policy may consume with- out 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 only enforced for sigqueue(2); 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- nal, a process must employ an alternate signal stack (sigalt- stack(2)). Since Linux 2.6.23, this limit also determines the amount of space used for the process’s command-line arguments and environ- ment variables; for details, see execve(2). RETURN VALUE On success, zero is returned. On error, -1 is returned, and errno is set appropriately. ERRORS EFAULT rlim points outside the accessible address space. EINVAL resource is not valid; or, for setrlimit(): rlim->rlim_cur was greater than rlim->rlim_max. EPERM An unprivileged process tried to use setrlimit() to increase a soft or hard limit above the current hard limit; the CAP_SYS_RESOURCE capability is required to do this. Or, the process tried to use setrlimit() to increase the soft or hard RLIMIT_NOFILE limit above the current kernel maximum (NR_OPEN). CONFORMING TO SVr4, 4.3BSD, POSIX.1-2001. 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 specified in POSIX.1-2001; it is nevertheless present on most implementations. RLIMIT_MSGQUEUE, RLIMIT_NICE, RLIMIT_RTPRIO, RLIMIT_RTTIME, and RLIMIT_SIGPENDING are Linux-specific. NOTES A child process created via fork(2) inherits its parent’s resource lim- its. Resource limits are preserved across execve(2). One can set the resource limits of the shell using the built-in ulimit command (limit in csh(1)). The shell’s resource limits are inherited by the processes that it creates to execute commands. 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 actual ceiling for the nice value was calculated as 19 - rlim_cur. This was fixed in kernel 2.6.13. Kernels before 2.4.22 did not diagnose the error EINVAL for setrlimit() when rlim->rlim_cur was greater than rlim->rlim_max. SEE ALSO dup(2), fcntl(2), fork(2), getrusage(2), mlock(2), mmap(2), open(2), quotactl(2), sbrk(2), shmctl(2), sigqueue(2), malloc(3), ulimit(3), core(5), capabilities(7), signal(7) COLOPHON This page is part of release 3.22 of the Linux man-pages project. A description of the project, and information about reporting bugs, can be found at http://www.kernel.org/doc/man-pages/. Linux 2008-10-06 GETRLIMIT(2)