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.
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)).
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.
# forum != support
Posté par Krunch (courriel, site web personnel) . En réponse au message un petit up ? samba kernel lock up. É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.