Unerklärliche Wirkung von Forkbombs

Computer: Software & Programmierung UNIX & Linux
#1

Hallo,

ich habe zum Spass mal probiert, wie sich forkbombs auf meinem Laptop auswirken. Ich habe mir dazu folgendes kleines Progrämmchen geschrieben:

#include 
#include 

int main(int argc, char\*\* argv){
 pid\_t a = 0;
 while(1){
 a += fork();
 }
}

dann habe ich das ganze mit gcc kompiliert und mit ./a.out gestartet. Wenn ich das nach ein bis zwei Sekunden mit Ctrl+C abbreche, dann läuft der Laptop normal weiter. Ausser einer hohen load average bleiben keine Spuren zurkück.

Heute es ist mir aber passiert, dass ich die forkbomb abgebrochen habe, und noch minuten später kam bei jedem Versuch, ein Programm zu starten, nur der Fehler „Ressource temporarily unavailable“. Dabei sollte doch durch das SIGINT die ursprüngliche forkbomb abgeschossen werden, und durch die folgenden SIGHUPs alle childs ebenfalls sterben.

Wieso konnten andere Prozesse trotzdem nicht forken? Wo liegt mein Denkfehler?

moritz@rena:~\>uname -a
Linux rena 2.6.9 #19 Wed Apr 20 13:26:22 CEST 2005 i686 GNU/Linux

Viele Grüße,
Moritz

#2

Hallo Moritz,

ich kann leider keine Erklärung geben, aber

Heute es ist mir aber passiert, dass ich die forkbomb
abgebrochen habe, und noch minuten später kam bei jedem
Versuch, ein Programm zu starten, nur der Fehler „Ressource
temporarily unavailable“.

Aber von diversen Versuchen (2.4) ist mir das vertraut.
Gruß,
Markus

#3

Hallo,

Versuch, ein Programm zu starten, nur der Fehler „Ressource
temporarily unavailable“.

Aber von diversen Versuchen (2.4) ist mir das vertraut.

Mir auch. Aber eigentlich nur, solange die forkbomb lief, wenn ich es geschafft habe sie abzuschiessen, dann nicht mehr. Das war in diesem Fall anders.

Grüße,
Moritz

#4

Hallo Moritz,

ja, bei mir auch, nach dem sie gekillt wurde. Man kann auch nette Systemzustände bekommen, wenn man init stresst. Aber auch dort habe ich mich mit den Gründen nicht beschäftigt.
Grüssle,
Markus

#5

Hallo,

der Witz ist, dass, wenn genug Prozesse laufen, diese schneller neue Kinder erzeugen, als sie abgeschossen werden. Man tötet diese, indem man ihnen erst ein
„halt“ und dann ein „term“ schickt.

Genauer: Das Prozesslimit vberhindert irgendwann, dass weitere Childs erzeugt werden - es können aber auch keine anderen Prozesse gestartet werden. Stirbt nun ein Prozess, so wird sofort genau ein weiteres Child erzeugt - die anderen Childs rufen ja weiterhin dauernd fork auf, nur bekommen sie halt meistens einen Fehler zurück. Schickt man ihnen ein halt, so wird dies zwar auch im Prinzip „zu langsam“ zugestellt, das macht aber nichts, da der Prozess weiterhin da ist, das Prozesslimit also ausgeschöpft bleibt und keine neuen „laufenden“ Childs entstehen können.

Ich habe mal probeweise eine Fork-Bombe geschrieben, in der sich die Childs wechelseitig „continue“-Signale schicken, das hat aber nur etwas gegen
halt->kill genutzt, wenn ich die Priorität von „halt“ künstlich gesenkt habe. Vermutlich braucht man damit dies funktioniert wirklich sehr viele Prozesse.

MfG
ML

#6

Hallo,

der Witz ist, dass, wenn genug Prozesse laufen, diese
schneller neue Kinder erzeugen, als sie abgeschossen werden.

das erklärt einiges

Man tötet diese, indem man ihnen erst ein
„halt“ und dann ein „term“ schickt.

nette Idee - wenn man noch ein killall starten könnte - oder zumindest ein ps um die pids rauszufinden (gibts kill nicht irgendwie als bash-builtin? bin mir grad nicht sicher…)

Ich habe mal probeweise eine Fork-Bombe geschrieben, in der
sich die Childs wechelseitig „continue“-Signale schicken, das
hat aber nur etwas gegen
halt->kill genutzt, wenn ich die Priorität von „halt“
künstlich gesenkt habe. Vermutlich braucht man damit dies
funktioniert wirklich sehr viele Prozesse.

hört sich richtig nett an *g*

Grüße,
Moritz