À la suite du tuyau dans x | y , un sous-shell est créé pour contenir le pipeline dans le cadre du groupe de processus de premier plan. Cela continue à créer des sous-shells (via fork() ) indéfiniment, créant ainsi une bombe à fourche.
$ for (( i=0; i<3; i++ )); do
> echo "$BASHPID"
> done
16907
16907
16907
$ for (( i=0; i<3; i++ )); do
> echo "$BASHPID" | cat
> done
17195
17197
17199
Cependant, le fork ne se produit pas tant que le code n'est pas exécuté, ce qui est l'invocation finale de : dans votre code.
Pour démonter le fonctionnement de la fourche bombe :
:()- définir une nouvelle fonction appelée:{ :|: & }- une définition de fonction qui dirige de manière récursive la fonction appelante vers une autre instance de la fonction appelante en arrière-plan:- appeler la fonction fork bomb
Cela a tendance à ne pas être trop gourmand en mémoire, mais cela aspirera les PID et consommera des cycles CPU.
Le dernier bit du code, ;: exécute la fonction :(){ ... } . C'est là que la bifurcation se produit.
Le point-virgule termine la première commande, et nous en commençons une autre, c'est-à-dire en invoquant la fonction : . La définition de cette fonction inclut un appel à elle-même (: ) et la sortie de cet appel est redirigée vers une version en arrière-plan : . Cela soutient le processus indéfiniment.
Chaque fois que vous appelez la fonction :() vous appelez la fonction C fork() . Cela finira par épuiser tous les ID de processus (PID) sur le système.
Exemple
Vous pouvez remplacer le |:& avec autre chose pour avoir une idée de ce qui se passe.
Configurer un observateur
Dans une fenêtre de terminal, procédez comme suit :
$ watch "ps -eaf|grep \"[s]leep 61\""
Configurer la bombe à fourche "fusible retardé"
Dans une autre fenêtre, nous exécuterons une version légèrement modifiée de la bombe à fourche. Cette version tentera de s'autoréguler afin que nous puissions étudier ce qu'elle fait. Notre version dormira 61 secondes avant d'appeler la fonction :() .
Nous allons également mettre en arrière-plan l'appel initial, après son appel. Ctrl + z , puis tapez bg .
$ :(){ sleep 61; : | : & };:
# control + z
[1]+ Stopped sleep 61
[2] 5845
$ bg
[1]+ sleep 61 &
Maintenant, si nous exécutons le jobs commande dans la fenêtre initiale, nous verrons ceci :
$ jobs
[1]- Running sleep 61 &
[2]+ Running : | : &
Après quelques minutes :
$ jobs
[1]- Done sleep 61
[2]+ Done : | :
Vérifiez auprès de l'observateur
Pendant ce temps, dans l'autre fenêtre où nous exécutons watch :
Every 2.0s: ps -eaf|grep "[s]leep 61" Sat Aug 31 12:48:14 2013
saml 6112 6108 0 12:47 pts/2 00:00:00 sleep 61
saml 6115 6110 0 12:47 pts/2 00:00:00 sleep 61
saml 6116 6111 0 12:47 pts/2 00:00:00 sleep 61
saml 6117 6109 0 12:47 pts/2 00:00:00 sleep 61
saml 6119 6114 0 12:47 pts/2 00:00:00 sleep 61
saml 6120 6113 0 12:47 pts/2 00:00:00 sleep 61
saml 6122 6118 0 12:47 pts/2 00:00:00 sleep 61
saml 6123 6121 0 12:47 pts/2 00:00:00 sleep 61
Hiérarchie des processus
Et un ps -auxf affiche cette hiérarchie de processus :
$ ps -auxf
saml 6245 0.0 0.0 115184 5316 pts/2 S 12:48 0:00 bash
saml 6247 0.0 0.0 100988 468 pts/2 S 12:48 0:00 \_ sleep 61
....
....
saml 6250 0.0 0.0 115184 5328 pts/2 S 12:48 0:00 bash
saml 6268 0.0 0.0 100988 468 pts/2 S 12:48 0:00 \_ sleep 61
saml 6251 0.0 0.0 115184 5320 pts/2 S 12:48 0:00 bash
saml 6272 0.0 0.0 100988 468 pts/2 S 12:48 0:00 \_ sleep 61
saml 6252 0.0 0.0 115184 5324 pts/2 S 12:48 0:00 bash
saml 6269 0.0 0.0 100988 464 pts/2 S 12:48 0:00 \_ sleep 61
...
...
Temps de nettoyage
Un killall bash arrêtera les choses avant qu'elles ne deviennent incontrôlables. Faire votre nettoyage de cette façon peut être un peu lourd, une manière plus douce et plus douce qui ne risque pas de déchirer tous les bash shell down, serait de faire ce qui suit :
-
Déterminez dans quel pseudo terminal la bombe fork va s'exécuter
$ tty /dev/pts/4 -
Tuez le pseudo terminal
$ pkill -t pts/4
Alors que se passe-t-il ?
Eh bien chaque invocation de bash et sleep est un appel à la fonction C fork() du bash shell à partir duquel la commande a été exécutée.