Forum Linux.debian/ubuntu un petit up ? samba kernel lock up

Posté par .
Tags : aucun
0
7
déc.
2012

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 . É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 . Évalué à 2.

    tout est dans le titre

  • # forum != support

    Posté par (page perso) . Évalué à 3. Dernière modification le 08/12/12 à 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 . É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 . É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 . Évalué à 2.

        reste à voir si tu peux le supprimer completement sans perdre de fonctionnalité

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.