Trop de fichiers ouverts

Bonjour,

Je suis sous linux et gcc 4.2.1, et j'ai un code en developpement plutot complexe avec des dizaines de threads et de connections ftp en même temps. Enfin un vrai micmac. Voila aprés quelque jour d'utilisation j'ai droit à un plantage du genre

Code:

---

1 2	GLib-ERROR **: Cannot create pipe main loop wake-up: Trop de fichiers ouverts

---

J'ai bien essayer d'augmenter la nombre fichiers ouverts en même temps autorisé avec la func "setrlimit(RLIMIT_NOFILE,&corelimit)" mais si ca va surement me permettre de durer plus longtemps ce n'est évidemment pas satistfaisant. J'ai regardé un peut partout si j'oublié pas de fermer des fichiers ouvert mais sans rien trouver.

Enfin y a-til moyen connaitre le nombre de fichiers ouverts dans un programme qui tourne, cela me permettrait de trouver le soucie.

Merci d'avance

Bonjour,
As tu jeter un oeil sur ce site http://www.linuxplusvalue.be/mylpv.php?id=203.
J'espère que cela pourra d'aider.
A bientôt

lsof ?

Oui "WAKAN" comme je disais j'ai déjà regardé de ce coté, mais le probleme n'est pas là à priori.

Isof ???

lsof est une commande sur les systèmes unix.
man lsof pour plus d'info

sous linux, on peut simplement regarder dans le répertoire /proc/pid/fd pour avoir la liste des fichiers ouverts à un instant donné par le processus qui a pour numéro pid.

Et pour traçer les ouvertures et fermetures de fichiers d'un processus au cours du temps, il y a la commande strace qui peut aussi être bien utile.

Je n'ai pas ce type de répertoire sous Suze !

Citation:

---

Envoyé par uriotcea

Je n'ai pas ce type de répertoire sous Suze !

---

Ah. Ca peut arriver mais si c'est une version pas trop vieille c'est quand même inattendu. Ca produit une erreur si sous un shell tu lances la commande suivante:

Code:

---

ls -l /proc/$$/fd

---

??
(ça liste les fichiers du processus shell)

Le moyen c'est simple, c'est de faire en sorte que ton programme ne fuit pas des ressources...
Utilise le RAII.

Ok j'ai finit par trouver ce répertoire et surveiller mon code. A priori le nombre fichier ouvert est constant est faible. Je ne comprend donc pas ce type de plantage
C'est Quoi RAII

Citation:

---

Envoyé par uriotcea

C'est Quoi RAII

---

http://arb.developpez.com/c++/raii/shared_ptr/

Ça pue la mauvaise traduction en fait.

Ce qu'il n'arrive pas à créer, ce n'est pas un fichier, mais un pipe. Probablement, leak de handle, mais pas nécessairement de fichiers.

lance ton programme avec strace (regarde les options de strace, et grep est ton ami).

Exact je vient de m'n rendre compte c'est les pipe de mes ftp qui visiblement pose problem. Au moment d'un plantage avec ce message j'avais ~150pipes d'ouvert. Est-ce beaucoup ?

Salut,
Sur mon ordi j'ai une limite a 256. Mais j'ai l'impression que cela commence a faire pas mal.
bye

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) 6144 file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 256 pipe size (512 bytes, -p) 1 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 266 virtual memory (kbytes, -v) unlimited

---

Apres des heures de tests laborieux, j'ai trouvé que mon plantage etait due à un SIG_PIPE.
Alors je peux les ignorer par
signal(SIG_PIPE,SIG_IGN)
Mais mes ftp sont dans des thread séparés. Ou dois je mettre cette instruction et n'est ce pas simplement repouser le probleme plus loing?

Tu dois t'assurer de fermer les tubes en question une fois qu'ils ne sont plus utilisés, mais à part ça...

Alors là, je ne sais pas trop comment fermer le pipe. Mes pipe sont créer sous Qt4 via la class Qftp

Normalement, si tu appelles bien close() sur tes objets QFtp, il ne devrait pas y avoir de soucis.

Est-ce que tu fais bien un join sur les threads que tu crées ? (wait() dans QThread).

white_tentacle , pourrais-tu etre plus explicite concernant 'un join' ?

Normalement, quand tu crées un thread, et qu'il se termine, tu dois le "joindre", au moyen de pthread_join sous posix.

Après, sous QT, je ne sais pas comment c'est fait, il y a bien wait(), mais peut-être que le join est aussi fait dans le destructeur (l'inverse métonnerait beaucoup).

Je pense que tu perds des threads, c'est à dire que tu crées des QThreads, mais que tu ne les détruits jamais (ou pas tous). Tes threads tiennent l'objet QFtp, qui du coup n'est jamais libéré, du coup tu exploses en nombre de pipe.

Ok je comprend, en fait je crée les threads une fois pour toute et je ne l'ai detruit qu'a la fin du traitement. Chaque thread faisant des centaines voire des milliers d'accé ftp.

Concernant les close() sur QFtp, il me semble que close() envoie un message de fin au serveur, mais que la liaison est rompu, le close() ne se termine pas non plus, il me semble

Si ton nombre de threads est limité, tout va bien de ce côté. Il faut donc chercher ailleurs. close() ferme la connection mais ne détruit pas l'objet QFtp.

Regarde si tu détruits bien tes objets QFtp (s'ils sont alloués dynamiquement).

Une solution est peut-être de passer par un pool de connexion et une file d'attente, parce que tu ne peux pas avoir trop de connexion ftp ouvertes à la fois.

Je ne sais pas ce que tu entends par limité, j'atteind aisémen la centaine.
De plus j'ai l'impression que faire un close() sur un ftp qui est en attente de réponse ou planté, cause plus de soucies que d'autre chose. Je fais plutot un abord(), mais là je suis pas tres compétant !

S'il n'y a pas de problème de libération de ressource et que ton programme utilise un nombre trop important de ressource jusqu'à atteindre la limite autorisée, tu peux utiliser un gestionnaire de ressource qui t'évitera d'avoir ce problème. En gros, tu lui donnes une limitation maximale, et quand elle l'atteint, alors, les proccess doivent attendre qu'une nouvelle ressource se libère avant de l'utiliser.

Mais bon, je ne sais pas si c'est ton vrai problème en occurrence...

Citation:

---

Je ne sais pas ce que tu entends par limité, j'atteins aisément la centaine.

---

Par limité, j'entends que tu n'en crées pas à la volée, et donc, tu ne peux pas (facilement) les perdre.

Par contre, comment se fait-il que tu aies besoin d'autant de thread ? Il y aurait un problème de conception là-derrière que ça ne m'étonnerait pas.

abort(), de même que close(), ne te détruira pas l'objet QFtp. Si tu le crées dynamiquement (au moyen de new), il faut que tu le détruises de la même manière (au moyen de delete).

Historiquement, je gérais une petite dizaines de machines via mon client via des thread séparé par commodité. ca fonctionnait parfaitement. Depuis, cause aquisition cluster , je suis passé à plus de 100, j'aurais du probablement revoir le concepte, mais manque de temps .
Maintenant j'aimerai bien deleter mes QFtp, mais malheureusement cette operation est fortement instable! Il semblerait que ce soit due à un probleme sur cette class de Qt

Salut,

Pour supprimer tes instances de QFtp, as-tu tenté d'appeler close(), de stocker l'id de l'action lancée, puis d'appeler delete (ou peut-être deleteLater, j'ai un trou) lorsque le signal commandFinished correspondant à l'id du close est reçu ?

Le problem que j'ai est quand je pert la connection pour une raison indéterminé (type perte de server) mes command, close() compris ne me rendent jamais la main, le signal commandFinished n'est jamais émit. Je ne sais pas pourquoi et surtout pourquoi n'y a t-il pas un time_out !

close() étant asynchrone, je serais assez étonné que cet appel ne te rende pas la main. Ou bien c'est lié à ton manque d'architecture prévue pour autant de threads (on n'a toujours pas de détails sur ta stratégie de répartitions de tâches si je n'ai raté aucun message ;)).

Je suis d'accord qu'un timeout est manquant à cette classe (peut-être dans une prochaine version...), mais c'est trivial à implémenter par toi même. Et si ce n'est pas déjà fait, il faudrait le faire, et lorsque le timeout est reçu, tu supprimes les actions en attente, tu déconnectes les slots et supprime ton instance.

L'architecture est la suivante:
Un client repartie sur N machine un certain nombre de calcul completement independant mais tres gourmand. ce client creer pour chaque machine un thread dans lequel est gerer les dialog avec la machine distance.
Un thread general dialog et gére cette ferme de thread donc de machine.

Trés simple et efficace pour une dizaine de machine, commence à etre limite pour une centaine. Mais pour info, cela fonctionne trés bien maintenant que j'ai redirigé SIGPIPE->SIG_IGN

Citation:

---

Mais pour info, cela fonctionne trés bien maintenant que j'ai redirigé SIGPIPE->SIG_IGN

---

À mon avis, ça ne plante plus mais ça ne marche pas, c'est juste que tu ne t'en aperçois pas.

Sinon, pour Qftp, visiblement, il faut attendre qu'il soit en état Unconnected pour le deleter.

Merci, Je vais essayer ca.
Sinon, j'insiste ca fonctionne parfaitement maintenant, l'appli manage correctement son parc de machines et recoit les resultats attendues, les quelques connections invalides qui généraient un SIGPIPE et faisaient planter l'appli sont maintenant transparente. J'en crée de nouvelle quand elles se plantent voila tout.
Je dois maintenant manager correctement leurs fermeture pour eviter de saturer le systeme au bout de quelques semaines.

Merci à tous de vos conseils éclairés