La fuite de mémoire peut arriver, mais il faut
Essaye de faire un «top» régulier pour voir si tu as un processus qui gonfle. Regarde dans le syslog.
Alors, on va essaer de répondre dans l’ordre :
@Num’s : J’ai un macbookpro, y a même pas de f13 en fait.
@lol : 2.68 Go de ram (3 moins les 512 Mo partagé avec la carte graphique), 1.86 de swap (j’avais mis 2 Go à l’install). Je pense pas qu’il y ait de soucis de ce coté la.
laurent@imrryr ~ % free -m
total used free shared buffers cached
Mem: 2745 2569 176 0 129 1498
-/+ buffers/cache: 941 1804
Swap: 1907 0 1907
@silver.sax : le systême ne plante pas en fait, il devient juste tellement lent que même la moindre manip va prendre un temps extrêmement long. Et lancer un top pendant le plantage, c’est pas faisable, ça prendrait beaucoup trop de temps. Et non c’était pas flash, c’était amule. flash m’a déja bouffé pas mal de mémoire (en fait gnash) et me prenant plus de 30Mo de ram par appli flash chargées dans firefox, mais c’est tout.
@panthere : pas de soucis de ce coté la non plus, mon cable réseau n’était pas branché mais mon réseau wifi local si, c’est un réseau non sécurisé que je crée (si je mets du wep ou du wpa, j’arrive pas à connecter mon ipod dessus) mais mes règles iptables filtrent tout ce qui ne vient pas d’une ip et d’une mac précise :
[code]root@imrryr laurent # service firewall status
filter table:
Chain INPUT (policy DROP 5 packets, 824 bytes)
pkts bytes target prot opt in out source destination
3 4056 ACCEPT all – * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT tcp – * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
0 0 ACCEPT icmp – * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all – lo * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT udp – eth1 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67
0 0 ACCEPT tcp – eth1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:67
0 0 ACCEPT udp – eth1 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
0 0 ACCEPT tcp – eth1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all – eth0 eth1 0.0.0.0/0 10.42.43.66 state RELATED,ESTABLISHED
0 0 ACCEPT all – eth1 eth0 10.42.43.66 0.0.0.0/0 MAC 00:25:BC:F4:B8:89
Chain OUTPUT (policy ACCEPT 3 packets, 156 bytes)
pkts bytes target prot opt in out source destination
nat table:
Chain PREROUTING (policy ACCEPT 1 packets, 99 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all – * * 10.42.43.0/24 !10.42.43.0/24
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
mangle table:
Chain PREROUTING (policy ACCEPT 8 packets, 4880 bytes)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 8 packets, 4880 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 3 packets, 156 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 3 packets, 156 bytes)
pkts bytes target prot opt in out source destination[/code]
@fran.b : oui c’était ça, amule qui tournait en tache de fond, et qui ne répondait plus (enfin qui réagissait plus du tout aux clics sur son icone dans le systray alors que les autres réagissait un peu).
Ça vient de me refaire le coup, mais par chance, je m’en suis rendu compte avant que la ram ne soit saturée (j’avais mon conky sous les yeux et vu la ram quasi pleine et un des coeur qui bossait pas mal). J’ai eu le temps de lancer le moniteur système et de faire une capture, sachant que la mémoire utilisée par amule a dépassé les 2 Go avant que je lui termine son processus.
À noter que je bidouillais sur wicd en même temps, je me demande si ça n’aurait pas un rapport, j’ai l’impression qu’amule pête une pile quand on lui coupe le réseau.
amule est connu pour ses fuites, tu peux essayer une autre version ou bien le lancer dans un shell en ayant utiliser ulimit
ulimit -S -m 5000000 -v 5000000 limite la RAM et le swap à resp 500M et 500M par exemple. Mais ça fera planter amule. Tu peux faire un cron qui le tue mais je crois que ça pose souci de faire des arrêts redémarrage rapprochés. Le mieux serait de trouver une version sans fuite.
D’accord, je vais faire ça la prochaine fois, merci pour l’astuce.
aMule?? HADOPI te guette, ils t’ont pirater ta machine!!
3 4056 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED tu devrai appliquer sa seulment a l’udp et tcp. ! certin protocole ne gere pas la machine d’état (ou du moins quand j’avai lu la doc il y a un bon moment) d’autre son la a titre expérimental dans le kernel…
sinon comme le dit fran.b utilise plus amule sa t’évitra pas mal d’emmm***
+1 pour aMule, qu’il utilise plutôt rtorrent pour télécharger des images iso de distrib’ GNU/linux 
Bah d’un hadopi peut aller se pendre, je suis même pas en France, et de deux qui a dit que je téléchargeait du contenu illégal ?
Ça ne me sert qu’à trouver des vieux trucs comme des émissions ou des trucs du genre. Bon c’est peut-être illégal, mais je suis pas sur qu’on vienne vraiment me faire un procès pour avoir téléchargé des émission d’arte.
Et ce genre de trucs, ça se trouve pas ailleurs.
@panthère : ok je vais modifier ça.
Ah! t’énerves pas cyphaw.
C’était pour rigoler et ironiser sur HADOPI…
Je ne t’accuse de rien 
[quote=“M3t4linux”]Ah! t’énerves pas cyphaw.
C’était pour rigoler et ironiser sur HADOPI…
Je ne t’accuse de rien [/quote]
Oh je ne m’énerve pas, t’inquiètes, désolé si ça semblait être le cas. Faut vraiment que je me mette à utiliser des smileys.
Et c’est pas ce qui manque sur ce forum. 
mai lol, z’avez pas compris que si vous taxer trop les riches il voir ailleur… un certain jonny sa vous dit quelque chose…
sa ser a rien de les taxer s’il ne son pas là
Personne n’a encore codé le programme “pampers” contre les fuites ?
Même pas un 1er Avril ? 
[quote=“piratebab”]Personne n’a encore codé le programme “pampers” contre les fuites ?
Même pas un 1er Avril ? [/quote]
Tussors !
Re,
Et ça règle le problème ?
Si oui passe en résolu le sujet. Merci.
[quote=“lol”]Re,
Et ça règle le problème ?
Si oui passe en résolu le sujet. Merci.[/quote]
J’ai pas testé, vu que je lance amule que très ponctuellement, mais je suppose que ça devrait, et c’était plus pour la discussion qu’un réel problème, donc je coche (je reviendrais peut-être dire ce qu’il en est si ça se reproduit).
[quote=“panthere”]3 4056 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
Tu devrais appliquer ça seulement à l’udp et tcp. Certains protocoles ne gèrent pas la machine d’état[/quote]
Conseil sans le moindre fondement. As-tu quelque chose de concret pour l’appuyer ?
[quote=“PascalHambourg”][quote=“panthere”]3 4056 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
Tu devrais appliquer ça seulement à l’udp et tcp. Certains protocoles ne gèrent pas la machine d’état[/quote]
Conseil sans le moindre fondement. As-tu quelque chose de concret pour l’appuyer ?[/quote]
j’ai plus exactement le pourquoi du comment mai sa ce rapportai aux protocole, stcp en experimental dans le kernel
le problème semble avoir été résolut depuis. car la doc que j’utilise a aussi evoluer
linux-france.org/prj/inetdoc … ctpmatches
+2 version bref sa date quoi 