Sie haben wahrscheinlich eine Linux-Distribution, die systemd verwendet.
Systemd erstellt eine Kontrollgruppe für jeden Benutzer, und alle Prozesse eines Benutzers gehören derselben Kontrollgruppe an.
Cgroups ist ein Linux-Mechanismus, um Systemressourcen wie maximale Anzahl von Prozessen, CPU-Zyklen, RAM-Nutzung usw. zu begrenzen. Dies ist eine andere, modernere Ebene der Ressourcenbegrenzung als ulimit (der den getrlimit() verwendet Systemaufruf).
Wenn Sie systemctl status user-<uid>.slice ausführen (das die Kontrollgruppe des Benutzers darstellt), können Sie die aktuelle und maximale Anzahl von Aufgaben sehen (Prozesse und Threads), die innerhalb dieser Kontrollgruppe erlaubt ist.
$ 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
Standardmäßig beträgt die maximale Anzahl von Tasks, die systemd jedem Benutzer zulässt, 33 % des "systemweiten Maximums" (sysctl kernel.threads-max ); dies beläuft sich in der Regel auf ~10.000 Aufgaben. Wenn Sie dieses Limit ändern möchten:
-
In systemd v239 und höher wird der Benutzerstandard über TasksMax= festgelegt in:
/usr/lib/systemd/system/user-.slice.d/10-defaults.confUm das Limit für einen bestimmten Benutzer anzupassen (das sowohl sofort angewendet als auch in /etc/systemd/system.control gespeichert wird), führen Sie Folgendes aus:
systemctl [--runtime] set-property user-<uid>.slice TasksMax=<value>Die üblichen Mechanismen zum Überschreiben der Einstellungen einer Einheit (wie
systemctl edit) können hier ebenfalls verwendet werden, erfordern jedoch einen Neustart. Zum Beispiel, wenn Sie das Limit für alle ändern möchten Benutzer, könnten Sie/etc/systemd/system/user-.slice.d/15-limits.conferstellen . -
In systemd v238 und früher wird der Benutzerstandard über UserTasksMax= gesetzt in
/etc/systemd/logind.conf. Das Ändern des Werts erfordert im Allgemeinen einen Neustart.
Mehr Infos dazu:
- man 5 systemd.resource-control
- man 5 systemd.slice
- man 5 logind.conf
- http://0pointer.de/blog/projects/systemd.html (durchsuchen Sie diese Seite nach cgroups)
- man 7 cgroups und https://www.kernel.org/doc/Documentation/cgroup-v1/pids.txt
- https://en.wikipedia.org/wiki/Cgroups
Das bringt moderne Linux-Systeme sowieso nicht mehr zum Absturz.
Es erstellt Horden von Prozessen, verbraucht aber nicht wirklich viel CPU, wenn die Prozesse im Leerlauf sind. Ihnen gehen die Slots in der Prozesstabelle aus, bevor Ihnen jetzt der RAM ausgeht.
Wenn Sie nicht cgroup-eingeschränkt sind, wie Hkoof betont, bringt die folgende Änderung immer noch Systeme herunter:
:(){ : | :& : | :& }; :
In den 90er Jahren habe ich versehentlich eine davon auf mich selbst losgelassen. Ich hatte versehentlich das Ausführungsbit in einer C-Quelldatei gesetzt, die einen fork()-Befehl enthielt. Als ich darauf doppelklickte, versuchte csh, es auszuführen, anstatt es wie gewünscht in einem Editor zu öffnen.
Selbst dann stürzte das System nicht ab. Unix ist robust genug, dass Ihr Konto und/oder das Betriebssystem ein Prozesslimit haben. Was stattdessen passiert, ist, dass es super träge wird und alles, was einen Prozess starten muss, wahrscheinlich fehlschlägt.
Was hinter den Kulissen passiert, ist, dass sich die Prozesstabelle mit Prozessen füllt, die versuchen, neue Prozesse zu erstellen. Wenn einer von ihnen beendet wird (entweder weil beim Fork ein Fehler auftritt, weil die Prozesstabelle voll ist, oder weil ein verzweifelter Operator versucht, sein System wieder in Ordnung zu bringen), wird einer der anderen Prozesse fröhlich einen neuen forken, um ihn zu füllen die Leere.
Die "Fork Bomb" ist im Grunde ein sich unbeabsichtigt selbst reparierendes System von Prozessen mit der Mission, Ihre Prozesstabelle voll zu halten. Die einzige Möglichkeit, es zu stoppen, besteht darin, sie alle auf einmal irgendwie zu töten.