開発システム(Ubuntu 21.10デスクトップ)の1つで実行されているカスタムアプリケーションがエラーでクラッシュしますsocket: Too many open files
。だからすぐに制限を確認してみました。出力は次のとおりです。
$ ulimit -n
65535
これが奇妙な理由は、アプリケーションがクラッシュしたときに1019ソケットのみを使用したためです。おそらく他のファイル記述子が開いていることを考えると、1024の制限に達したようです。
デスクトップにulimit -n
制限が65535であることが明確に示されていますが、1024の制限を課すのはなぜですか?
もっと奇妙にするためです。 2つのアプリケーションがあります。 1つはepoll
Webスクレーパーに基づいており、もう1つは接続を開始するために複数のWebサーバーにメッセージを送信するPACKET_MMAP
アプリケーションに基づいています。SYN
アプリケーションはepoll
クラッシュしませんが、1024よりもはるかに多くのソケットを使用します。そして、PACKET_MMAP
rawソケットを使用する基本的なアプリケーションがクラッシュしました。
さらに、サーバーでテストしたのと同じアプリケーション(Ubuntuも実行)は競合しません。
したがって、問題が何であれ、デスクトップと生のソケットアプリケーションにのみ当てはまります。
編集する:
cat /proc/pid/limits
必要に応じて出力:
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 31106 31106 processes
Max open files 1024 1048576 files
Max locked memory 1025802240 1025802240 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 31106 31106 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
出力は、最大オープンファイルのソフト制限が実際には1024であることを示しています。これはulimit -n
次のように一致します。
ベストアンサー1
ユーザーとプロセスによってリソース制限を異なるように設定できます。特定のユーザーの特定の制限が表示されますulimit
が、systemd
独自の既定の制限があります。systemd
ファイル制限を設定するには、プログラムのユニットファイルを更新する必要があります。LimitNOFILE=1048576
バラより文書詳しくは