経由でルートユーザーと非ルートユーザーのオープンファイル制限を増やそうとしています/etc/security/limits.conf
。しかし、を超える999999
ことができず、この値を超えるとデフォルトに戻り、1024
無制限に設定することもできません。
これが私のlimits.conf
* hard nofile 999999
* hard nofile 999999
root hard nofile 999999
root soft nofile 999999
上記は正常に動作し、ulimit -n
戻ります999999
。
しかし、値を1段階高くしたり、またはにしたりunlimited
して-1
も機能infinity
しません。ulimit -n
1024
こちらを参考にしました:limits.conf - pam_limits モジュールの設定ファイル | Ubuntu マニュアルページ
ありがとう
答え1
10 か月遅れであることは承知していますが、すべてのユーザーに対してハード制限を 2 回設定しています。2 行目をソフト ulimit に変更してください。
* hard nofile 999999
* soft nofile 999999
root hard nofile 999999
root soft nofile 999999
これを実行すると、次のように表示されます。
$ ulimit -n
999999
$
制限が正しく定義されているため、ファイルは常に root に対して機能するはずです。
さらに、-1、無限大、無制限などは使用できません。リテラル値を使用する必要があります。これに対してサポートされている最大値はカーネルで定義されており、/proc/sys/fs/nr_open で公開されています。私の Centos 7 および Debian strech 環境では、同じ値が得られます。
$ cat /proc/sys/fs/nr_open
1048576
$
制限を更新するには、新しいセッションを開始する必要があります。
答え2
これを機能させるには、次の 3 つのファイルを変更する必要があります。
/etc/security/limits.conf
/etc/pam.d/common-session
/etc/pam.d/common-session-noninteractive
最初のファイルには必要な行がすでに追加されていますが、他の 2 つのファイルには次の行が必要です。
session required pam_limits.so
ご注意ください:
ほとんどのリソースが強調していないのは、プロセスの実行に責任を持つものによって制限が簡単に変更される可能性があるということです。ulimit -n (適切なユーザーとして実行) で設定した数値が返されても、cat /proc/{process_id}/limits で低い数値がまだ表示される場合は、プロセス マネージャー、init スクリプト、または同様のものによって制限が台無しになっている可能性がほぼ確実です。また、プロセスは親プロセスの制限を継承することにも留意する必要があります。
したがって、そのようなプロセスが存在する場合は、それを機能させるために構成ファイルを変更する必要があります。
ソース: https://underyx.me/2015/05/18/raising-the-maximum-number-of-file-descriptors