J'ai rencontré un petit bug que je suspecte d'avoir un lien avec samba.
Toute l'explication est là http://linuxfr.org/forums/linuxdebianubuntu/posts/samba-kernel-lock-up.
On m'a très justement fait remarquer qu'une stack trace serait la bienvenue pour confirmer ou infirmer le bug.
J'ai récupérer cette information et elle également là http://linuxfr.org/forums/linuxdebianubuntu/posts/samba-kernel-lock-up#comment-1412755 .
Malheureusement j'ai l'impression que trop de temps c'est écouler entre ma demande et les stack trace et que mon post est tombé dans l'oubli.
Je me permet un petit up ici même dans la mesure où je suis incapable d’interpréter ces infos.
Merci d'avance pour vos lumières.
# NAS pour faire apparaître ce bug
Posté par hitmanu . Évalué à 1.
Je n'ai pas de NAS pour faire apparaître ce bug, j'utilise Samba sur mon serveur Debian Squeeze et tous fonctionne.
Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.
# pourquoi ne pas avoir fait le UP sur le post d'origine ?
Posté par NeoX . Évalué à 2.
tout est dans le titre
# forum != support
Posté par Krunch (site web personnel) . Évalué à 3. Dernière modification le 08 décembre 2012 à 12:44.
Si tu veux du vrai support tu ferais sans doute mieux de t'adresser aux mainteneurs de ta distribution ou à quelqu'un que tu paierais spécifiquement pour ce service.
Cela dit, parmi
http://pastebin.com/3guq6PkD
http://pastebin.com/qMENTziq
http://pastebin.com/KEGZ8adn
seul le premier indique clairement un blocage. Le second montre que l'application elle même s'est mise en attente d'un signal tandis que la 3ème montre un process qui est en train de se faire tuer par un signal. Si ces deux processes sont effectivement bloqués, ils sont en attente de quelque chose d'autre qu'un sysrq-t pourrait peut-être montrer.
Ce premier process est bloqué sur un open(2) qui se fait via FUSE. Je sais pas ce que tu fabriques avec FUSE puisqu'il y a moyen d'avoir Samba/CIFS comme un « vrai » filesystem. Dans tous les cas, on voit encore une fois que le process est en attente d'un autre composant (FUSE) et il faudrait donc examiner ce que cet autre process/task est en train de faire.
Si on regarde
http://pastebin.com/NjCeddfD
on retrouve une situation similaire (juste que cette fois le problème est déclenché via close(2)).
http://pastebin.com/3dW2sut4 et http://pastebin.com/N8NBVAPk n'ont a priori aucun intérêt.
Comme indiqué précédemment, sysrq-t et tcpdump (lancé avant que le problème n'apparaisse) serait sans doute des bonnes pistes pour poursuivre l'investigation. Mais je m'interroge quand même sur l'utilité de FUSE dans ce contexte.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: forum != support
Posté par mike.simonson . Évalué à 1.
Pour le moment j'essaie simplement de savoir à qui je dois envoyer le rapport de bug.
Tes conclusions sur fuse sont donc précieuse pour moi et en plus elles collent avec l'impression que je en avais.
Personnellement je n'utilise pas Fuse, mais on dirait que c'est ça que nautilus utilise quand on passe par la fonctionnalité "Browse Network". Ça pourrait aussi expliquer pourquoi ce problème n'est pas encore survenu quand je lis les films avec xbmc.
Maintenant je dois trouver la combinaison de touche qui active sysrq sur mon clavier et rediriger le résultat de t dans un fichier ???
Ensuite je pourrai faire un rapport de bug exploitable par gnome et fuse.
Merci beaucoup
[^] # Re: forum != support
Posté par mike.simonson . Évalué à 1.
Effectivement, c'est fuse qui est responsable du crash, tout est rentré à la normale quand je l'ai tué.
[^] # Re: forum != support
Posté par NeoX . Évalué à 2.
reste à voir si tu peux le supprimer completement sans perdre de fonctionnalité
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.