
私のシステムulimit -u
レポート63172
と/proc/sys/kernel/pid_max
レポート情報32768
。
の値がulimit -u
カーネルの値より高いのはなぜですか?私が理解したのは、ulimit -u
システム全体の最大プロセスではなく、ユーザーが持つことができる最大プロセスです。pid_max
カーネルを介してシステム全体で実行する必要があります。ulimit -u
それより高い値は間違っているようです。pid_max
ユーザーが十分なプロセスを作成すると、PIDのラップアラウンドが発生する可能性がありますか?また、pid_max
ユーザーが実行するアクションによって値が影響を受けると、このようなNo more processes error
ことが起こりますか?
答え1
PIDする通常の使用中にサラウンドします。これはまったく問題ではありません。カーネルは、新しいPIDが既存のPIDと衝突しないことを保証します。 PIDが単調に増加しなければならないという内容はありません。プロセス12345は、容易にfork()
サブプロセス5001を有することができる。
この場合、はい、ユーザーはすべてのプロセススロットを使用し、追加の種類のアクティビティfork()
が発生しないようにすることができます。これがあなたの環境で問題になる場合は、ulimit値を調整する必要があります/etc/security/limits.conf
。/etc/security/limits.d/*
答え2
これは通常、ユーザーの制限に達する前にシステムのプロセススロットが不足していることを意味します。マニュアルページには次のようsetrlimit
に記載されています。
RLIMIT_NPROC
呼び出しプロセスの実際のユーザーIDに対して生成できるプロセスの最大数(より正確にはLinuxではスレッド)。この制限に達すると、
fork(2)
エラーで失敗しますEAGAIN
。この制限は、または機能を持つプロセスにはCAP_SYS_ADMIN
適用されませんCAP_SYS_RESOURCE
。
戻り値は、EAGAIN
これが同時スレッドの制限であることを強く示唆し、サブスレッドが終了すると、後続のスレッドが成功する可能性がfork()
あります。