☰

OS X/MacOS/BSD 最大ファイルサイズ設定

tag-icon • tag-icon osx bsd ulimit
OS X/MacOS/BSD 最大ファイルサイズ設定

私のOS Xコンピュータに、プロセスごとに許可されている開かれたファイルの数を追跡する問題があります。maxfilesコマンド表示オプションを使用する場合launchctl（limit私のOS X El Capシステムで）

$ launchctl limit
    cpu         unlimited      unlimited      
    filesize    unlimited      unlimited      
    data        unlimited      unlimited      
    stack       8388608        67104768       
    core        0              unlimited      
    rss         unlimited      unlimited      
    memlock     unlimited      unlimited      
    maxproc     709            1064           
    maxfiles    256            unlimited

ソフト制限は256、ハード制限は「制限なし」のようです。ソフト制限を同様の値に変更し、2048ハード制限を同じにしたいと思います。limit彼らの主張を見ると

$ launchctl help limit
Usage: launchctl limit [<limit-name> [<both-limits> | <soft-limit> <hard-limit>]

同じことに2つの制限を設定できるようです。またはソフトとハードの値を設定します。しかし、制限のない厳格な制限を設定しようとすると

$ sudo launchctl limit maxfiles 2048 unlimited

私は奇妙な値10240で終わりました。

$ launchctl limit
    cpu         unlimited      unlimited      
    filesize    unlimited      unlimited      
    data        unlimited      unlimited      
    stack       8388608        67104768       
    core        0              unlimited      
    rss         unlimited      unlimited      
    memlock     unlimited      unlimited      
    maxproc     709            1064           
    maxfiles    2048           10240

ここで何が起こっているのでしょうか？値を無制限に設定できますか？それ以外の場合、これはコマンドの制限ですかlaunchctl limit、それともシステムレベルの制限ですか？後者の場合、unlimitedレポートの初期値は何ですか？それとも、このリンゴはただのリンゴですか？

ボーナスポイントの場合 - 当初、この制限がなぜそんなに低く設定されているのか知っている人はいますか？

ベストアンサー1

これがXNU、FreeBSD、TrueOS、OpenBSDの共通点です。いいえ制限なしオープンファイル記述子のハードおよびソフト制限。さまざまなオペレーティングシステムカーネルにはさまざまな動作がありますが、RLIMIT_NOFILESこの機能の制限設定を許可しません。RLIM_INFINITYsetrlimit()

これはこれらすべてで完全に文書化されていません。

文書化されていない動作は、データセグメント、スタックセグメント、ユーザーあたりの最大プロセス数、および最大オープンファイルディスクリプタの数に対するソフトおよびハード制限が、すべてのsysctlカーネル変数の値によって制限されることです。カーネル変数が各制限に制限されるなどの詳細は、オペレーティングシステムによって異なります。

  • XNU で権限を持つプロセスは、開かれたファイル記述子の制限をkern.maxfilesカーネル変数より高く設定することはできません。権限のないプロセスは、開かれたファイル記述子の制限をkern.maxfilesperprocカーネル変数より高く設定することはできません。 コードは次のとおりです。
  • FreeBSD と TrueOS では、プロセスは開かれたファイル記述子の制限をkern.maxfilesperprocカーネル変数より高く設定できません。 コードは次のとおりです。
  • OpenBSD では、プロセスは開かれたファイル記述子の制限をkern.maxfilesカーネル変数より高く設定できません。 コードは次のとおりです。

これらすべてにも帽子は沈黙しています。このsetrlimit()呼び出しはエラーを返しません。プログラムが必要とする値より下限値を簡単かつ静かに設定します。 （XNUには「POSIXモード」があります。柔らかい上限を超えて制限します。しかし、設定硬いこれにより、他のオペレーティングシステムと同様に制限が自動的に制限されます。 ) プログラムが制限適用を無効にしようとすると、これらのオペレーティングシステムでは制限上限値がオペレーティングシステムレベルで適用され続けます。

RLIM_INFINITY厳密に言えば、これはエラーが返されず、その動作を自動的に提供しないことを要求し、提供しない単一のUnix仕様に違反することです。

RLIM_INFINITY成功した呼び出しで指定されたリソース制限値は、setrlimit()そのリソース制限の適用を無効にします。

launchctl limitlaunchdマニュアルに示すように、このコマンドはプロセスにsetrlimit()独自のプロセスリソース制限を設定するように呼び出すように指示する方法にすぎません。だからあなたが見るのはlaunchdプロセスですスタート開かれたファイルディスクリプタの数に無限のハード制限を置き、次に有限の制限を受け、開かれたファイルディスクリプタの数にkern.maxfilesperproc無限のハード制限を設定し、最初の試みで置くハードオープンファイル記述子の制限は無制限です。

（FreeBSD / TrueOSでも同じことが起こります。ここで、プロセス＃1は開かれたファイル記述子の高いハード制限から始まり、プロセス＃1プログラムは明示的にハード制限を下限にリセットします）。

（実際には、GNOMEターミナルサーバープロセスが最初に親プロセスから開かれたファイル記述子の厳格な制限を継承するオペレーティングシステムで発生した場合、ターミナルセッションを開始できなくなる非常に迷惑なバグがGNOMEターミナルにあります。kern.maxfiles現在の値が/より高い場合このエラーが発生する可能性がありますkern.maxfilesperproc。 GNOME端末の作成者は、元の致命的なエラーを読み取ったのと同じ値にハード制限を設定できなかったと見なします。, GNOME 端末が XNU/BSD 動作をトリガして自動的にハード制限を下げてコードが最終的に試みるということを考慮せずに増加するそれは、失敗の理由である。 )

kern.maxfilesperproc10240は、XNUのカーネル変数用にコンパイルされた初期値です。しかしそうではありません。かなりとても簡単です。システムの起動時にサーバーのパフォーマンスモードにあるとき、XNUはこの変数をスケール値の75000倍に初期化します。。

おすすめ記事