Comment diagnostiquer les gels aléatoires?

Ubuntu semble toujours se figer dans les ~ 15 premières minutes de son démarrage sur ma machine. Parfois, c'est dans les 5 premières minutes, parfois cela prend 30 minutes, parfois ça n'arrive jamais ...

Je ne peux pas le reproduire de manière déterministe, mais cela arrive assez souvent de toute façon que j'attends probablement que cela se reproduise.

Comment puis-je diagnostiquer le gel pour en déterminer la cause ?

Note aux électeurs proches:
Non, ce n'est pas un double de cette question. Cette question concerne le diagnostic , pas une guérison temporaire. Les réponses à cette question ne me disent que comment tuer le serveur X, utiliser le Magic Combo pour réinitialiser le noyau, etc .... ce qui ne m'aide pas à en trouver la cause.

Des informations:

1. Ubuntu 11.04: 2.6.38-15-générique # 66-Ubuntu SMP x86_64 GNU / Linux

2. La souris se déplace parfois , mais l'interface utilisateur ne répond jamais .

3. Appuyez sur Ctrl+ Alt+ F1pour accéder à un terminal ne fonctionne pas.

4. Les Alt+ SysRqcombos font le travail ... et semblent être les seules choses que le travail, en dehors de la souris (qui peut parfois se déplacer).

5. Je ne manque de ressources (de nombreux gigaoctets de RAM et d'espace de système de fichiers sont gratuits)

6. Matériel éventuellement pertinent (à partir de l'application Hardware Lister):

   • Carte réseau sans fil AR9285 (PCI-Express)

   • GT216 [GeForce GT 330M] (j'utilise le pilote Nouveau, qui semble bien fonctionner)

Les journaux doivent toujours être votre premier port d'escale. Vérifiez syslog pour tout élément indésirable:

less /var/log/syslog

Vérifiez également les journaux Xserver au cas où il y aurait une indication d'un problème de pilote graphique (bien que cela semble moins probable compte tenu de votre description):

less /var/log/Xorg.0.log

Dans votre cas particulier, ces étapes pourraient ne rien faire d'intéressant. Dans ce cas, je serais intéressé de voir ce qui se passe sur votre système au moment où le problème se développe. À cette fin, personnellement, je mettrais en place un journal de topsortie temporaire à de courts intervalles - disons toutes les 5 ou 10 secondes. J'espère que cela devrait révéler si un processus est en cours d'exécution avec des ressources au moment du problème.

Notez qu'il existe des alternatives, telles que le passage à un autre tty avec Ctrl+Alt+F1.. F6(pour revenir à l'interface graphique, c'est Ctrl+Alt+F7) et l'exécution de commandes de manière interactive, ou la configuration d'un serveur SSH et la connexion à distance. Les deux peuvent être gênants si votre machine ne répond plus ou non, d'où ma suggestion plus maladroite d'écrire un fichier journal (qui pourrait également rencontrer le même problème, mais a plus de chances de réussir).

Cela impliquerait quelque chose comme ceci:

while [ 1 -eq 1 ] ; do top -b >> ~/top.log; sleep 10; done

Cela écrirait la topsortie dans un fichier journal à ~ / top.log toutes les 10 secondes environ. Notez que ce journal deviendrait assez volumineux si cette commande est exécutée pendant une période prolongée, alors gardez un œil dessus si votre machine commence soudainement à se comporter! Et supprimez le journal rm ~/top.loglorsque vous avez terminé. Notez également que l'exécution de la commande ci-dessus est une opération unique; il ne redémarrera pas après un redémarrage.

Pour lire les journaux générés après un crash, vous devez utiliser

less ~/top.log

et appuyez sur la Endtouche pour aller au fond. Vous recherchez des processus avec une valeur CPU% anormalement élevée ou une valeur RES anormalement élevée.

Cela peut ou peut ne pas aider, mais c'est une information pratique à avoir.