おそらく、systemd を使用する Linux ディストリビューションをお持ちでしょう。
Systemd はユーザーごとに cgroup を作成し、ユーザーのすべてのプロセスは同じ cgroup に属します。
cgroups は、プロセスの最大数、CPU サイクル、RAM 使用量などのシステム リソースに制限を設定する Linux メカニズムです。これは、ulimit とは異なる、より最新のリソース制限レイヤーです。 (これは getrlimit() を使用します システムコール)
systemctl status user-<uid>.slice を実行すると (ユーザーの cgroup を表します)、タスクの現在および最大数を確認できます その cgroup 内で許可されている (プロセスとスレッド)。
$ systemctl status user-$UID.slice
● user-22001.slice - User Slice of UID 22001
Loaded: loaded
Drop-In: /usr/lib/systemd/system/user-.slice.d
└─10-defaults.conf
Active: active since Mon 2018-09-10 17:36:35 EEST; 1 weeks 3 days ago
Tasks: 17 (limit: 10267)
Memory: 616.7M
デフォルトでは、systemd が各ユーザーに許可するタスクの最大数は、「システム全体の最大数」(sysctl kernel.threads-max) の 33% です。 );これは通常、約 10,000 タスクに相当します。この制限を変更したい場合:
-
systemd v239 以降では、ユーザーのデフォルトは TasksMax= で設定されます で:
/usr/lib/systemd/system/user-.slice.d/10-defaults.conf特定のユーザーの制限を調整するには (すぐに適用され、/etc/systemd/system.control に保存されます)、以下を実行します:
systemctl [--runtime] set-property user-<uid>.slice TasksMax=<value>ユニットの設定をオーバーライドする通常のメカニズム (
systemctl editなど) ) もここで使用できますが、再起動が必要になります。たとえば、すべての制限を変更したい場合 ユーザー、/etc/systemd/system/user-.slice.d/15-limits.confを作成できます . -
systemd v238 以前では、ユーザーのデフォルトは UserTasksMax= で設定されます
/etc/systemd/logind.confで .通常、値を変更するには再起動が必要です。
これに関する詳細情報:
- man 5 systemd.resource-control
- man 5 systemd.slice
- man 5 logind.conf
- http://0pointer.de/blog/projects/systemd.html (このページで cgroup を検索)
- man 7 cgroup と https://www.kernel.org/doc/Documentation/cgroup-v1/pids.txt
- https://en.wikipedia.org/wiki/Cgroups
いずれにせよ、これで最近の Linux システムがクラッシュすることはなくなります。
大量のプロセスが作成されますが、プロセスがアイドル状態になるため、実際にはそれほど多くの CPU が消費されることはありません。 RAM が不足する前に、プロセス テーブルのスロットが不足しています。
Hkoof が指摘するように cgroup が制限されていない場合でも、次の変更によりシステムがダウンします:
:(){ : | :& : | :& }; :
90 年代にさかのぼると、私は誤ってこれらの 1 つを自分自身に解き放ちました。 fork() コマンドを含む C ソース ファイルに誤って実行ビットを設定してしまいました。ダブルクリックすると、csh は希望どおりにエディターで開くのではなく、実行しようとしました。
それでも、システムはクラッシュしませんでした。 Unix は十分に堅牢なので、アカウントや OS にはプロセス制限があります。代わりに、非常に遅くなり、プロセスを開始する必要があるものはすべて失敗する可能性があります.
舞台裏で起こっていることは、新しいプロセスを作成しようとしているプロセスでプロセス テーブルがいっぱいになることです。それらの 1 つが終了した場合 (プロセス テーブルがいっぱいになったために fork でエラーが発生したか、システムに正気を取り戻そうと必死になったオペレーターが原因で)、他のプロセスの 1 つが喜んで新しいものを fork して埋めます。ボイド。
「フォーク爆弾」は基本的に、プロセス テーブルをいっぱいに保つという使命を帯びた、意図せずに自己修復するプロセスのシステムです。それを止める唯一の方法は、どういうわけかそれらを一度に殺すことです.