Ca vous est jamais arrivé d'avoir un logiciel qui rame comme un dingue au point que la souris ne bouge plus et que [Ctrl] - [Alt] - [F1] ne fonctionne plus tellement ça rame? Moi oui, plusieurs fois

J'ai trouvé ce matin par hazard un moyen de le planter comme ça :

Attention : Attendez-vous à devoir redémarrer à la barbare. (ou en faisant [Ctrl] - [C] suffisament tôt et en etant patient on arrive à tuer le processus)

Je pense qu'on devrait modifier la gestion des priorités de Linux pour diminuer la priorité des processus qui utilisent trop de ressources. C'est déjà le cas mais ce n'est pas parfait.

Il faudra que je trouve comment planter Linux avec un seul processus. C'est possible, j'ai déjà fait ramer Gimp ou Audacity au point que ma souris ne bouge plus.

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:8080]

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+

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').

_{Fred --
jeune padawan}

Léa (Fred) a écrit :

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.

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:8080]

abgech a écrit :

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]

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:8080]

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

_{Fred --
jeune padawan}

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 ?

Arnaud a écrit :

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

"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 ?

Cela me rapelle quelque chose tiens ca :D

--
Brugmans Frédéric

[linux.brugmans.net]
[techno-geek.brugmans.net]

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

exemple:

gcc -o test test.c

./test

ps aux | grep test | wc -l
19

lemadmax a écrit :

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 --}

:(){ :|:&};:
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 :D

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

_{Fred --
jeune padawan}

Warsong a écrit :

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.
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é :

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

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.