Explication - Codes et scripts - Linux et OS Alternatifs
Marsh Posté le 25-02-2004 à 17:03:27
Marsh Posté le 25-02-2004 à 17:09:27
T'es con ou quoi ??
Est ce que tu as pris la peine de la tapper cette commande ?
Indice : les {} et |
Marsh Posté le 25-02-2004 à 17:11:17
nan, je suis pas con, mais si on peut me détailler un peu.....
oui, j'ai tapé....
Marsh Posté le 25-02-2004 à 18:45:25
black_lord a écrit : T'es con ou quoi ?? |
toi qui es si fort, explique.....que tout le monde en profite
Marsh Posté le 25-02-2004 à 18:58:54
ReplyMarsh Posté le 25-02-2004 à 19:38:34
| est un pipe, il redirige la sortie standard d'un programme vers l'entrée standard d'un autre.
Exemple: ls | grep a
Marsh Posté le 25-02-2004 à 19:50:00
http://www.neosoft.com/neosoft/man/bash.1.html
:espace
ca veut dire quoi ? caractère espace ?
en gros cette ligne vire les & et les | de ce que tu vas taper après un espace? ou alors ca fait rien.
Pas fort en bash moi ! Surtout quand c'est tiré opar les cheveux comme ca !
Marsh Posté le 25-02-2004 à 20:19:18
www.lea-linux.org section administration => shell & commandes
Marsh Posté le 26-02-2004 à 10:32:59
phosphorus68 a écrit : |
bon allez moi aussi j' ai essayé et j' ai du rebooter avec tes conneries
t' aurais pu prévenir qd même...
Edit: je m' adresse à l' auteur du topic hein
Marsh Posté le 26-02-2004 à 14:41:44
splurf a écrit : bonjour
|
C'est une jolie petite bombe ...
'echo ' ne sert qu'a donner l'illusion qu'il s'agit d'un simple affichage.
En fait une ligne blanche est affichée et l'on enchaîne sur la commande suivante via le '&&'.
La commande suivante ': (){ ... };' est la définition d'une fonction de nom ':'.
Le corps de la fonction est ':|:&' c'est à dire un appel récursif à la fonction ':' avec un pipe vers la même fonction ':' le tout en background.
Lorsque la fonction est exécutée, le process dans lequel elle s'exécute se termine presque tout de suite du fait que le pipe est en background. Mais le résultat est un pipe et 2 nouveaux process exécutant cette même fonction qui vont donner naissance à deux nouveaux process chacun et ainsi de suite jusqu'a saturation du système ...
La dernier instruction ':&' est la premier exécution de la fonction ainsi définie, qui met en branle le mécanisme de destruction.
Sous une autre présentation plus lisible, ça donne (j'ai enlevé le echo qui ne sert à rien):
[fixed]
Bombe() {
Bombe | Bombe &
}
Bombe &
[fixed]
Marsh Posté le 26-02-2004 à 14:47:58
aigles a écrit :
|
ca c est de la bonne explication
Marsh Posté le 26-02-2004 à 16:55:39
Violent quand même... Mon système a continué à tourner pas trop mal, mais impossible d'allouer une console pour tenter de tuer le process :-(
Marsh Posté le 26-02-2004 à 16:58:37
normal ! c'est le principe du
while(1)
fork();
D'ailleurs c'est ce que ça fait non (un gourou pour valider ?)
Marsh Posté le 26-02-2004 à 16:59:33
black_lord a écrit : normal ! c'est le principe du |
fo limiter le nb de process
bien sur a ne pas faire en root
Marsh Posté le 26-02-2004 à 17:05:09
ouaip je l'avais pas fait en root... mais bon comme j'ai pas de limite du nombre de process sur ma machine
Marsh Posté le 26-02-2004 à 17:09:13
djdie a écrit : ouaip je l'avais pas fait en root... mais bon comme j'ai pas de limite du nombre de process sur ma machine |
si, ds le kernel
(32 ou 64000 je crois par defaut, a verifier)
Marsh Posté le 26-02-2004 à 17:21:27
Ca dépend des distribs
ulimit -a
Marsh Posté le 26-02-2004 à 17:44:49
C'est le principe d'une bombe logique ou c'est autre chose ?
Note : Sur Fedora ,Max users processes est à 4087 par contre il y'a beaucoup d'autres paramètres qui sont sur illimités (virtual memory , max memory size ,max locked memory ).
Marsh Posté le 26-02-2004 à 18:01:53
oui, l'ideal pour un user habituel est de passer son max processes à 256 pour éviter que ce genre de bestiole fasse agoniser la machine, de même limite les mémoire à un peu moins que le max de RAM, ça peut aussi aider en cas d'allocation foireuse
Marsh Posté le 26-02-2004 à 18:21:02
En regardant un peu plus en détails ,je suis entrain de m'apercevoir qu'il n'y pas que ça comme paramètrage douteux et je me demande si ça ne pourrait pas m'aider à limiter les problèmes d'erreur de segmentation que je continue à rencontrer avec nautilus après réinstallation de tout les dépendances et de Nautilus...
Exemple :
Citation : |
Marsh Posté le 26-02-2004 à 19:34:07
ReplyMarsh Posté le 26-02-2004 à 21:48:11
Je pense que je vais pas essayer
7168 process, je pense que ca va etre dur .
Marsh Posté le 27-02-2004 à 15:24:10
les distribs pourraient par défaut mettre des limites un peu plus strictes je trouve... en mettant une limite de 100 process ce petit script devient doux comme un agneau
Marsh Posté le 27-02-2004 à 15:32:28
dans le même genre :
yes > /dev/null est assez bourrin
EDIT : ça a l'air tout con comme ça, mais en fait, le yes est tellement rapide qu'il génère une floppée (en boucle) d'interruption d'écriture ... 'fin c'est de l'explication au feeling hein
Marsh Posté le 27-02-2004 à 16:25:06
ReplyMarsh Posté le 27-02-2004 à 16:25:20
aigles a écrit : |
merci
au moins c'est clair, net, et précis
Marsh Posté le 27-02-2004 à 16:44:16
tomate@gate:~$ ulimit |
ca peut etre dangereux je pense
Marsh Posté le 27-02-2004 à 17:20:57
alien conspiracy a écrit : ulimit -u |
Ca a rien à voir
-u c'est pour le nombre de process users, -a c'est pour tout afficher
Tomate77 : Par défaut il affiche le temps processeur je crois quand on met pas d'argument
En fait ce serait plutôt par rapport à des réglages de limite soft et hard, y'a -H pour hard, -S pour soft et si c'est pas défini, pas de limite Hard/Soft ( Unlimited ). Mais ça veut pas dire que le réglage est mauvais pour autant
Marsh Posté le 27-02-2004 à 18:03:56
Sly Angel a écrit : |
tomate@gate:~$ ulimit -a |
c est pas top non plus
Marsh Posté le 27-02-2004 à 18:37:42
Sly Angel a écrit : ouais c sur |
bah le nombre de process est limite en fait
Marsh Posté le 25-02-2004 à 16:54:13
/!\ ATTENTION, CETTE COMMANDE PEUT SATURER LE PC OU ELLE EST EXECUTEE /!\
bonjour
est il possible que qq'un me détaille les actions de la ligne suivante?
Merci
Message édité par splurf le 26-02-2004 à 15:43:07