Diskussion:Forkbomb

message: Bei mir funktioniert while(fork()) nicht bzw. es stürzt nicht ab. Müsste daran liegen, dass die Kind-Prozesse abbrechen, da fork() in einem Kindprozess 0 zurückliefert. Ohne Bedingung hat man jedenfalls einen garantierten Absturz, weswegen ich while(fork()) mit for(;;)fork(); getauscht habe.
::Äh.. Nur mal so ne Frage, aber wirft da der Compiler nicht die Warnung, das es die Fork-Funktion nicht gibt? -- Master_M (nicht signierter Beitrag von 188.23.51.172 (Diskussion) 20:04, 5. Jun. 2010 (CEST)
replies: text: Bei solchen Beispielen ist es durchaus üblich offensichtlich notwendige include-Anweisungen oder ähnliches wegzulassen, um das Beispiel kurz und knapp zu halten bzw. nicht vom wesentlichen abzulenken. --Gms 23:51, 8. Jun. 2010 (CEST)
thread_title:  C-Code 

message: Der Java-Code in der jetzigen Fassung erzeugt keine neuen Prozesse, sondern neue Threads, d.h.
von der Betriebssystem-Seite bleibt es bei genau einem Prozess. Die immer mehr werdenden Threads
nehmen natürlich auch immer mehr Ressourcen in Anspruch bis sich das Programm irgendwann (vermutlich
mit out-of-memory) aufhängen wird. Die Maschine als solche ist (wenn man nicht noch andere Fehler
einbaut) nicht dadurch (ressourcenmäßig) gefährdet. Insofern ist das Java-Beispiel kein passendes Beispiel für eine Forkbomb. (nicht signierter Beitrag von 94.217.96.68 (Diskussion) 13:07, 22. Dez. 2012 (CET)
thread_title:  Java-Code 

message: "Aus einem Programmaufruf werden somit zunächst 2, dann 4, dann 8 und nach nur 10 solcher Zyklen sind bereits über tausend Kopien gestartet und aktiv."
Das stimmt mathematisch, der Realität entspricht es nicht. Die "Forkbomb" ist wie ein binärer Baum. Das beduetet, das jede Ebene die Zahl der Forks verdoppelt (soweit OK). Ein PC kann aber nicht in der gleichen Zeit, wie er 2 Forks startet, dan 4 Forks, 8 Forks, 16 Forks usw. gleichzeitig starten.
Der Computer benötigt also zum starten von 4 Forks die doppelte Zeit, wie das Starten von 2 Forks. Dementsprechend benötigt er für 8 Forks die vierfache Zeit, und für 512 Forks die 256 fache Zeit.
Wird das Programm rekursiv abgearbeitet, dann wird überhaupt nur ein Zweig abgearbeitet, und die Verästellungen werden gar icht erst durchlaufen.
Ach ja, da der Computer eine Obergrenze an aktivrn Prozessen haben wird, werden ab einem bestimmten Moment Prozesse in den Swap-Speicher ausgelagert werden, was den Ablauf noch verlansamt. Spätestens, wenn der Swap-Speicher voll ist ist Schluß.
Nebenbei: 1990 habe ich mal auf einer UNIX-Workstation etwas ähnliches laufen lassen. Das Program war ein Script, das im Hintergrund lief. Zweck des Programms war es, rekursiv einen vorgegebenen Binomialkoeffizienten zu berechnen, und zwar in dem Sinne, das jeder Scriptaufruf bis zu zwei weitere Scriptaufrufe zur Folge haben konnte, uns solange wartete, bis die aufgerufenen Scripte ihr Ergebnis zurücklieferten:
binkoeff n k -> binkoeff n-1 k + binkoeff n-1 k-1
Abbruchbedingungen:
binkoeff n 1 = 1
binkoeff n n = 1
Ein binkoeff 49 6 erzeugt also maximal an die 14 Millionen binkoeff Aufrufe.
--Arbol01 01:18, 14. Dez. 2008 (CET)
replies: text: Bist du dir mit der doppelten Zeit sicher? Nur weil ein Computer, sagen wir jetzt mal 1 Sekunde braucht um 2 solcher Forks zu starten, muss das nicht unbedingt heißen, dass er fuer 4 oppelt so lange braucht. Höchstens wenn das Erstellen eines Forks ihn voll auslastet, so dass er fuer jeden Fork gleich lange braucht, ich denke heutige Computer sind in der Lage 2 oder 4 Forks in der selben Zeit zu erzeugen, kann auch sein, dass ich mich irre, wenn ja, da korrigier mich bitte. -- Jorumpl 19:27, 19. Aug. 2009 (CEST)
replies: text: Deinem Zweifel würde ich auch zustimmen, das sollte möglichst allgemein gehalten werden. Felix D. (Diskussion) 17:27, 4. Sep. 2018 (CEST)
thread_title:  Nicht ganz korrekt! 

message: Der Phython Code ist kein Forkbomb, der ruft das Fork nicht rekursiv sondern in einer einfachen Schleife auf. Sollte den selben Effekt haben, aber ist laut der vorherigen Definition keine Forkbomb.
:Ohne auch nur ein Fitzelchen Python zu können würde ich das dann so vorschlagen:
import os
os.fork()
os.fork()
: -- RAMI 21:15, 18. Mär. 2009 (CET)
replies: text: Ich habe den Pythoncode mal rausgenommen, bis die Sache sicher geklärt ist. MfG, --Dr. Al. K. Lisch ?!  +/- 11:46, 30. Jul. 2009 (CEST)
thread_title:  Phyton Code 

message: Das Javascriptbeispiel ist auch keine Forkbomb, es ist einfach nur eine Endlosschleife. Sinnvoller wäre
function f(f) {
 f(f());
}
Und wie wäre es mit einem weiteren Beispiel für bash?
$0 | $0 &
--Twinity 15:44, 1. Mär. 2010 (CET)
replies: text: Na dann ist es doch sinnvoller das Java-Script Beispiel zu entfernen. Man kann ja im Artikel drauf hinweisen, dass man in Sprachen wie JavaScript keine Fork-Bomb schreiben kann. Ist vielleicht nicht jedem Leser direkt klar. --Gms 21:49, 16. Mär. 2010 (CET)
thread_title:  Javascript-Beispiel 

message: Die Kurzzusammenfassung ist meines Erachtens schon deshalb schlecht, weil sie den Begriff "Forkbomb" viel zu eng faßt: im Grunde kann doch jedes Programm, daß durch - rekursive oder nicht-rekursive - Mittel so lange Prozesse startet, bis die Prozeßtabelle überlädt (oder das Memory alle ist, was auch immer früher eintrifft), als "Forkbomb" bezeichnet werden. Daraus könnte man zB auch die - Anfängern immer wieder passierende - unabsichtliche Programmierung von Forkbomben ableiten: Programme, die das, was sie tun, mit einem Übermaß an zusätzlichen Prozessen tun, sodaß sie vielleicht mit kleinen Testdatensets gerade noch laufen, aber im realen Betrieb das System gegen die Wand fahren.
--bakunin (Diskussion) 11:22, 14. Mai 2013 (CEST)
thread_title:  Kurzzusammenfassung 

message: Im Artikel steht zur Zeit:
::Der konkrete Effekt einer Forkbomb hängt in erster Linie von der Konfiguration des Betriebssystems ab. Beispielsweise erlaubt PAM auf Unix- und Unix-ähnlichen Betriebssystemen die Zahl der Prozesse und den maximal zu verbrauchenden Speicher pro Benutzer zu beschränken.
Das ist völliger Unsinn: Erstens ist PAM (noch) kein Standard - und deshalb auch nicht "UNIX" - sondern nur vorläufig, siehe "XSSO". Zweitens wird die maximale Prozeßanzahl und die maximal zuzuteilende Memory-Menge pro User nicht von der PAM geregelt (was auch der Name - "Authentication Modules" - nahelegt), sondern durch den Kernel, der sich durch die PAM (sofern sie überhaupt verwendet wird, was nicht notwendigerweise der Fall ist) verifizieren läßt, wer der User grade ist. (->"Authentizierung") Beispielsweise stehen bei AIX diese Beschränkungen in /etc/security/limits in Stanza-Form (und vermutlich auch irgendwo in der ODM, ich habe noch nie danach gesucht) und die User-Verwaltung bedient sich dort.
--bakunin (Diskussion) 11:40, 14. Mai 2013 (CEST)
thread_title:  PAM beschränkt Prozeßanzahl 

message: Warum wird der Prozess in einigen Codebeispielen in einer Endlosschleife geforkt (vgl. C und PHP), obwohl es doch reichen sollte lediglich 2 Kopien seiner selbst zu erstellen (so wie es auch im Teil mit 2^n Kopien erklärt wird)? --MorbZ 08:55, 21. Apr. 2013 (CEST)
thread_title:  Endlosschleife