setを使用するシステムユーザーサービスがありますLimitNOFILE
。この値は4096に達するまで保持されます。それ以降は4096に制限されます。DefaultLimitNOFILE
増やしてみました/etc/systemd/user.conf
。
これはlimit.confに正しく設定されており、すぐに利用可能な新しいシェルで動作します。しかし、systemdはそのファイルに興味がないと聞きました。何が問題なのでしょうか?
答え1
遅い応答、
limits.conf
systemdが実行されているときは使用されません(limits.conf
非systemdシステムに適用されます)。
実際に必要なファイルは次のとおりです。/etc/systemd/system.conf
- これはグローバル構成です。これにより、/etc/systemd/user.conf
ユーザーごとの制限をさらに指定できます。
特に、お客様の場合は、より高い制限を構成しても、より低い制限があり、制限として機能するため、user.conf
何の効果もありません。system.conf
user.conf
Ao_Ao
答え2
からman systemd.exec
:
システムデバイスの場合、これらのリソース制限を自由に選択できます。ただし、ユーザー単位(つまり、systemd(1)のユーザー固有のインスタンスによって実行される単位)の場合、これらの制限には、オペレーティングシステムによって実行される(潜在的により制限的な)ユーザー固有の制限が適用されます。
システムは、プロセスごとに開かれたファイル数を4096に制限することで構成できます。 systemdがこの制限を迂回することを許可した場合、脆弱性が存在します。
答え3
これは、バージョン240より前のsystemdに関連している可能性があります。
望むより:https://github.com/systemd/systemd/blob/main/NEWS
240の変更点:...
- Linuxカーネルでは、現在のユーザースペースプロセスのデフォルトのRLIMIT_NOFILEリソース制限が1024(ソフト)と4096(ハード)に設定されています。以前は、systemdはそれを分岐したすべてのプロセスに変更せずに渡しました。。今回の systemd リリースでは、systemd が渡すハード制限が 512K に増加し、カーネルのデフォルト設定を無視し、権限のないユーザー空間プロセスで割り当てられる同時ファイル記述子の数が大幅に増加します。
したがって、systemdをバージョン240以降にアップグレードしてみてください。