ulimit -uが/proc/sys/kernel/pid_maxより高いのはなぜですか?

ulimit -uが/proc/sys/kernel/pid_maxより高いのはなぜですか?

私のシステム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()あります。

関連情報