Ah ça oui!

C'est surtout lorsque X déconne que c'est chiant... Une fois, la souris bouge, mais l'ordi semble gelé... Le clavier ne marche pas non plus... :,(:,(:,( Je me connecte en SSH (Télécharge Putty sur l'ordi de ma mère...). Ça marche, mon X prend toutes les ressources possible. Je le kill donc à la barbare, mais sur mon ordi, tout est encore gelé... Reboot obligé...

C'est très gênant lorsque ça l'arrive.

---
MaximeAD
Email: maximead@gmail.com
Jabber: maximead@jabberquebec.net
Page personnelle: [maximead.net]

Poste le Monday 9 January 2006 23:00:12

bonjour

comme je suis curieux, est-il possible de savoir sous quelle distrib vous arrivez a produire ces plantages ? (en particulier MaximeAD)

En fait, j'avais moi aussi de serieux plantages de X sous Mandrake avec mon portable (obligé de rebooter par ssh), mais depuis que je suis en Debian je n'ai plus aucun soucis...

a+

Poste le Tuesday 10 January 2006 17:26:10

Il n'est pas très étonnant que ce programme qui passe son temps à faire des "fork()" fasse un plantage du système : il lance des tonnes de processus (de manière recursive qui plus est). En fort peu de temps il donne des milliers voir des millions de processus à gérer au kernel, qui ne peut plus faire que passer son temps à passer d'un processus à l'autre, et comme la majorité des processus sont alors en train de se relancer eux-même ... il n'y a plus aucun temps pour faire autre chose.

Ceci dit, il est possible de protéger Linux contre cela, lis cela : [www.ossir.org] (cherche 'fork-bomb').

Poste le Tuesday 10 January 2006 18:02:47

Citation
Léa (Fred)
Il n'est pas très étonnant que ce programme qui passe son temps à faire des fork()" fasse un plantage du système : il lance des tonnes de processus (de manière recursive qui plus est). En fort peu de temps il donne des milliers voir des millions de processus à gérer au kernel, qui ne ...

Il ne peut en lancer au maximum 32767, le pid ne comporte que 16 bits et les valeurs négatives sont utilisées pour définir des cibles (pour les signaux) englobant plusieurs processus.

Cela dit, il passe son temps à répondre qu'il ne peut plus "forker" au delà de cette limite.

Poste le Tuesday 10 January 2006 18:07:21

J'ai fait ce plantage sous Debian 3.1 et c'est arrivé tout récemment.

---
MaximeAD
Email: maximead@gmail.com
Jabber: maximead@jabberquebec.net
Page personnelle: [maximead.net]

Poste le Tuesday 10 January 2006 22:53:59

Citation
abgech
Léa (Fred) a écrit :Il n'est pas très étonnant que
ce programme qui passe son temps à faire des
fork()" fasse un plantage du système : il lance
des tonnes de processus (de manière recursive qui
plus est). En fort peu de temps il donne des
milliers voir des millions de processus à gérer au
kernel, qui ne ...

Il ne peut en lancer au maximum 32767, le pid ne
comporte que 16 bits et les valeurs négatives sont
utilisées pour définir des cibles (pour les
signaux) englobant plusieurs processus.

Cela dit, il passe son temps à répondre qu'il ne
peut plus "forker" au delà de cette limite.

Je suis sous Gentoo 2005.1 avec un kernel 2.6.14 (gentoo-source).

Je le confirme aussi. J'ai bien pu faire le plantage aujourd'hui avec ce programme. Symptômes: X était gelé mais ma machine partagait toujours la connexion avec mon deuxième ordinateur (ssh a bien fonctionné mais il était assez lent).

J'ai compilé le programme avec cygwin pour tester sous Windows. À ma grande surprise, la souris pouvait encore bouger :-) (cela pourrait s'expliquer facilement car windows donne la priorité à l'interface graphique). Petit à petit, tous les programmes ont eu un "pas assez de mémoire" (zone alarm, explorateur) avant que Windows n'éteigne l'ordinateur (car la mémoire + le swap ont été consommés).

Le pdf est intéressant, merci Léa (Fred). Je vais l'enregistrer pour le lire un peu plus tard.

--
Asher256
[asher256.tuxfamily.org]

--
Asher256
Blog (qui parle en grande partie de GNU/Linux): [asher256.tuxfamily.org]

Poste le Wednesday 11 January 2006 00:20:16

La grande question serait de savoir si, plus tard, il y aura une amélioration dans la gestion des processus dans le noyau pour éviter des plantages comme ça. (Ou bien un X qui ne plante tout simplement pas)

---
MaximeAD
Email: maximead@gmail.com
Jabber: maximead@jabberquebec.net
Page personnelle: [maximead.net]

Poste le Wednesday 11 January 2006 14:05:00

Vous lisez les réponses ? Parce que ça existe, c'est justement l'objet des patchs 'grsec' et des options 'CONFIG_GRKERNSEC_FORKBOMB*'

Poste le Wednesday 11 January 2006 14:13:18

Remarque : la fork bomb relève plus de l'erreur de programmation que d'un bug du noyau. Et fork() est indispensable. En plus, la capacité de la bécane à supporter ça dépend fortement de la configuration.

--
Primo : rien de ce que j'écris ne saurait avoir a priori valeur de vérité universelle et incontournable.
Secundo : ce post est placé sous la DSSL (Demerden Sie Sich Licence).
Tertio : les barbus mangent du nioubie au p'tit-déj.
Quarto : z'avez vu, j'ai rajouté un tertio ?

Poste le Wednesday 11 January 2006 14:46:20

Citation
Arnaud
Remarque : la fork bomb relève plus de l'erreur de
programmation que d'un bug du noyau.

ben.. ca peut ête aussi l'oeuvre de petit mariols, qui vienne de voir un film sur les hackers qui luttent contre des mechants et plante le systeme unix avec un programme "lapin" (qui se reproduit par fork).
evidement si on est admin/responsable d'un systeme unix en fac (ou assimilé) on a prevu le cas

Poste le Thursday 12 January 2006 10:27:52

"fork() is not a bug, it's a feature."

--
Primo : rien de ce que j'écris ne saurait avoir a priori valeur de vérité universelle et incontournable.
Secundo : ce post est placé sous la DSSL (Demerden Sie Sich Licence).
Tertio : les barbus mangent du nioubie au p'tit-déj.
Quarto : z'avez vu, j'ai rajouté un tertio ?

Poste le Thursday 12 January 2006 10:53:20

Cela me rapelle quelque chose tiens ca

--
Brugmans Frédéric

[www.brugmans.net]
[triathlon.sport-challenge.be]

Poste le Thursday 12 January 2006 12:51:07

Il n'y a rien à corriger, c'est normal de pouvoir lancer autant de processus que l'on veut.
Tu peux empher ça en utilisant sysctl.conf, ou en faisant un petit ulimit -u 30

Poste le Thursday 12 January 2006 21:10:21

exemple:

gcc -o test test.c

./test

ps aux | grep test | wc -l
19

Poste le Thursday 12 January 2006 21:15:03

Citation
lemadmax
ps aux | grep test | wc -l
19

Hum, ça m'a l'air d'une commande bien bizarre, ça...
ps aux : afficher les processus
| grep test : on cherche "test"
| wc -l : puis on va avec tout ça aux toilettes, en prenant le chemin le plus long (option "-l").
19 : résultat, le test a duré 19 heures de l'affichage des processus à l'arrivée aux toilettes...
.
.
.
.
.
.
/me =======================> /o/ [ ]

.:! L'être humain est au sommet de la chaîne alimentaire. Certes. Mais il est surtout au sommet de la connerie et de la bêtise... !:.
-- Pour les nouveaux linuxiens : Ce n'est pas en continuant de faire ce que l'on connaît que l'on pourra faire ce que l'on ne connaît pas --

Poste le Sunday 15 January 2006 12:59:28

){ :|:&};:
essayer cette ligne de commande c'est un très bon moyen de planter un serveur en simple utilisateur attention c'est très rapide et le seul moyen c'est éteindre en bourrin voila

Poste le Thursday 9 February 2006 16:06:36

C'est une simple variante de la précédante.
){ :|:& } défini la fonction ":" qui est récursive, elle se « pipe » elle-même.
et :
){ :|:& };:
lance la fonction ":" après l'avoir créée.
Une version moins obscure est :
mafonction(){ mafonction | mafonction & }; mafonction

Poste le Thursday 9 February 2006 16:29:13

Citation
Warsong
){ :|:&};:
essayer cette ligne de commande c'est un très bon moyen de planter un serveur en simple utilisateur attention c'est très rapide et le seul moyen c'est éteindre en bourrin voila

Si tu connais le C, tu seras surement intéressé par ça : [www.ioccc.org]


Je viens de faire un autre programme pour planter Linux, sans fork mais en faisant saturer la mémoire.

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#define KO 1024
#define ALLOC 2047*KO*KO //Quantité de mémoire allouée (j'alloue ici 2Go mais ce n'est pas nécessaire, il suffit d'allouer plus que la RAM)
#define ALLOCTAB ALLOC/sizeof(int) //Nb de cases mémoire

int main() {
	nice(19); // Même en priorité minimale ça fait ramer
	int tab[ALLOCTAB];
	int i;
	puts("On commence a ecrire dans la memoire");
	for(i=0;i<ALLOCTAB;i++) {
		tab=0;
	}
	puts("On a fini d'ecrire dans la memoire");
	sleep(9999);
	return(0);
}

C'est ce genre de plantage que j'avais obtenu avec certains logiciels qui allouent plein de mémoire. Exemple : Avec Audacity j'édite 30 pistes audio et je clique sur "jouer", il les mixe et donc il charge les premières secondes des 30 pistes audio. Là j'ai tout le temps de le regretter : ça rame, il faut avoir énormément de patience pour lancer Xkill ou pour aller sur une console. Sur une console il faut encore se logger. J'ai pas réussi ("Login timed out after 60 seconds" avant d'avoir pu taper le mot de passe). Finalement ça s'arête quand le processus est tué :

$ dmesg
Out of Memory: Killed process 1240 (exe).
Out of Memory: Killed process 1240 (exe).

exe est le nom de mon programme de bug.
J'ai une idée de pourquoi ça bugge :

$ time exe
real    0m56.205s
user    0m0.640s
sys     0m10.360s

Le temps user est pratiquement nul, et le temps systeme est loin du temps réel. Les opération d'allocation de la mémoire sont donc effectuées par le noyau et le noyau ne sait pas qu'elles sont dues à ce programme. Le noyau pense donc que le programme n'utilise pas de ressource et lui donne la main tout le temps, et alors le programme appelle en permanance les fonctions systèmes qui font ramer.
Si ça rame autant c'est que même le temps système n'est pas pris en compte par l'ordonnanceur des taches. Si il était pris en compte il prendrait seulement 5 fois trop de ressources donc il resterait au moins 20% à l'interface graphique.

Poste le Wednesday 29 March 2006 16:47:29