Où sont les journaux de panique du noyau?

27

J'ai un problème avec Handbrake / ffmpeg. Après environ 5 minutes de transcodage, l'ordinateur se verrouille. Je suis assez sûr que c'est une panique du noyau parce que le verrouillage des majuscules commence à clignoter.

Il y a quelques questions logiques sur ce qu'il faut faire et sur des bugs spécifiques, mais je suis vraiment sur une chose: que s'est-il passé avant que tout soit mort?!

J'ai coché /var/log/kern.log et tout ce que je vois à la fois est que je colle un DVD puis quelques minutes plus tard, le système démarre. Pas d'erreurs, pas de panique.

Y a-t-il un moyen de forcer les paniques à être enregistrés? Je suis à peu près sûr que je peux reproduire ceci (c'est arrivé 100% des fois que j'ai essayé récemment), alors même si je préférais que cela "fonctionne", je suis assez content de redémarrer à quelques reprises si cela me permet trouver la cause de la panique.

    
posée Oli 16.02.2012 - 16:01
la source

3 réponses

19

Tous vos journaux système dans Ubuntu sont gérés par rsyslog qui conserve sa configuration en /etc/rsyslog.conf et /etc/rsyslog.d/ .

Pour plus d'informations sur la configuration de rsyslog et sur les options possibles, visitez le site. le rsyslog.conf man page .

Ouverture de /etc/rsyslog.d/50-default.conf vous pouvez voir que l’une des lignes contient

*.*;auth,authpriv.none -/var/log/syslog*

Ce qui signifie que le fichier que vous recherchez dans ce cas est l’un des énormes journaux /var/log/syslog que vous aurez probablement.

Vous pouvez voir que le nom du fichier commence également par - , ce qui signifie que le fichier est mis en cache avant d’écrire, ce qui est génial mais peut vous laisser avec un mauvais journal. Ce que vous voulez, c’est comme il y a un problème. Supprimez le tiret et redémarrez ou rechargez rsyslog , puis faites de nouveau basculer votre ordinateur, vérifiez /var/log/syslog .

    
réponse donnée Bruno Pereira 16.02.2012 - 16:57
la source
24

Si c'est vraiment une panique du noyau, il ne sera pas écrit dans un journal via les méthodes normales. Comme le noyau a été bloqué à ce moment-là, écrire dans le système de fichiers est une opération risquée - il est impossible de faire confiance à une grande partie du noyau.

Au lieu de cela, vous pouvez vider le contenu de la mémoire dans votre swap, puis le déboguer plus tard. Ceci est connu comme un crash / core dump.

Le wiki Ubuntu a un CrashdumpRecipe qui peut être utile - bien qu'il soit un peu obsolète, je ne Je pense que trop de choses auraient dû changer.

    
réponse donnée Caesium 16.02.2012 - 17:04
la source
2

Port série

Le port série est un simple mécanisme de communication de bas niveau entre ordinateurs.

Avantages:

  • configuration simple une fois (si vous avez le matériel)
  • fiable, car la transmission de données ne dépend que de simples fils et de l'API du noyau, moins susceptible d'être affectée par la panique que le sous-système TCP / IP.

Inconvénients:

  • la plupart des ordinateurs portables modernes n’ont plus le port série (exposé?) pour économiser de l’espace. Mais les ordinateurs de bureau et les machines virtuelles le font toujours.
  • vous avez également besoin d’un deuxième ordinateur avec un port série pour recevoir les données, mais c’est le cas pour pratiquement toutes les cartes de développement embarquées telles que le Raspberry Pi.
  • limitée par la longueur du câble série de la couche physique, contrairement aux réseaux TCP / IP qui sont illimités. Cela peut cependant être contourné avec un périphérique qui interface entre série et TCP / IP. Mais il existe des appareils qui convertissent entre les deux.

Le port série ressemble à ceci:

et sur le RPI est disponible via le GPIO.

Ensuite, si vous disposez du matériel requis, connectez-vous du deuxième ordinateur à l’ordinateur principal avec:

screen /dev/ttyS0 115200

Cela vous donne un shell.

Puis sur la machine principale, lancez l'opération qui panique.

Lorsque la panique se produit, le vidage de panique est diffusé sur la deuxième machine et vous pouvez tout voir en faisant défiler le terminal.

Autres méthodes

Il existe également d’autres méthodes permettant de surmonter les limitations matérielles mentionnées ci-dessus, au détriment de leur complexité et de leur fiabilité. Méthodes notables:

  • netdump: lance la panique sur TCP / IP. S'appuie sur le sous-système TCP / IP qui n'est pas corrompu.
  • kdump: semble être le mécanisme sous-jacent de linux-crashdump mentionné à l'adresse: lien Botte un deuxième noyau Linux à examiner le noyau écrasé. Qu'est ce qui pourrait aller mal?! :-)

Voir aussi cette excellente réponse: lien

Etape de débogage

En fin de compte, pour obtenir une sortie de panique, certaines fonctionnalités du noyau doivent fonctionner et toutes les fonctionnalités du noyau peuvent être corrompues par la panique.

Mais qui a besoin de panique si vous pouvez utiliser GDB sur le noyau? Si vous êtes ce hardcore, regardez:

  • QEMU ou autres VM: lien
  • JTAG

Chaque problème tombe une fois que vous avez une visibilité complète (et suffisamment de temps!).

    
la source

Lire d'autres questions sur les étiquettes