web-dev-qa-db-fra.com

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 de toute façon, cela arrive assez souvent que j'attends probablement que cela se reproduise.

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

Note aux électeurs proches:
Non, ceci est pas une copie de this question. Cette question concerne le diagnostic et non une récupération temporaire. Les réponses à cette question me disent seulement comment tuer le serveur X, utiliser Magic Combo pour réinitialiser le noyau, etc., ce qui ne m'aide pas à comprendre la cause.

Des informations:

  1. Ubuntu 11.04: 2.6.38-15-generic # 66-Ubuntu SMP x86_64 GNU/Linux

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

  3. Pressage Ctrl+Alt+F1 entrer dans un terminal ne fonctionne pas.

  4. Le Alt+SysRq Les combos fonctionnent ... et semblent être les seules choses qui fonctionnent, mis à part la souris (qui peut parfois aussi se déplacer).

  5. Je ne manque de ressources (plusieurs giga-octets de RAM et l'espace du système de fichiers sont libres)

  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)

11.04freeze
13
Mehrdad

Les journaux doivent toujours être votre premier point d’appel. Vérifiez syslog pour tout élément indésirable:

less /var/log/syslog

Consultez é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 générer aucune information intéressante. 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 temporaire top publié à intervalles rapprochés - toutes les 5 ou 10 secondes, par exemple. Cela devrait, espérons-le, révéler si un processus est en cours d'exécution avec des ressources au moment du problème.

Notez que des alternatives existent, telles que le passage à un autre terminal 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, sinon ma suggestion plus délicate d'écrire un fichier journal (qui pourrait rencontre également 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

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

Pour lire les journaux générés après un crash, utilisez

less ~/top.log

et frapper le End clé pour aller au fond. Vous recherchez des processus avec une valeur de processeur exceptionnellement élevée ou une valeur de RES inhabituellement élevée.

Cela peut aider ou ne pas aider, mais il est utile d'avoir des informations pratiques.

7
IlluminAce